Website Accessibility (WCAG): Guide 2026

Website Accessibility (WCAG): The Complete Guide 2026

Web accessibility is no longer an optional nice-to-have – it's a legal obligation, an ethical responsibility, and a tangible business advantage. In Austria, around 1.4 million people live with a disability; across Europe, the figure is over 87 million. Add to that millions of older users and people with temporary limitations. An accessible website reaches all these people – and simultaneously offers a better user experience for every single visitor.

At GoldenWing, we have been using [method/method] for over 3 years.accessible websitesand understand the challenges, legal requirements, and practical solutions. This comprehensive guide tells you everything you need to know about website accessibility in 2026.

What is website accessibility?

Website accessibility means that a website is designed and developed so that it can be used by everyone – regardless of physical, sensory, or cognitive abilities. This includes people with:

• Visual impairments:Blindness, visual impairment, color blindness
• Hearing impairments:Deafness, hearing impairment
• Motor impairments:Impaired fine motor skills, paralysis, tremor
• Cognitive limitations:Learning disabilities, ADHD, autism, dementia
• Temporary restrictions:Broken arm, eye inflammation, noisy environment
• Situational limitations:Sunlight on the screen, one-handed operation on the bus

The curb-cut effect

In urban planning, there's the "curb-cut effect": curb cuts were introduced for wheelchair users but are used equally by parents with strollers, delivery drivers with trolleys, and cyclists. The same thing happens on the web: accessible websites are easier to use for everyone.

Clear heading structures help not only screen reader users but also readers in a hurry. Good contrast makes reading easier in sunlight. Keyboard navigation is faster than the mouse, even for power users. Accessibility is not an exception – it's good practice.web design.

Legal requirements: EU, Austria and DACH

The legal requirements for accessible websites have become significantly stricter in recent years. Companies that fail to act now risk warnings and substantial fines.

European Accessibility Act (EAA)

The European Accessibility Act (Directive (EU) 2019/882) has been binding in all EU member states since June 28, 2025. It obliges companies offering digital products and services to ensure accessibility. This affects, among other things:

• E-commerce websites and online shops
• Banking services and financial products
• Telecommunications services
• E-books and e-readers
• Passenger transport services
• Products with a digital interface

Important:The EAA doesn't just affect large corporations. SMEs with 10 or more employees or an annual turnover of 2 million euros or more are also subject to the regulation. Micro-enterprises are exempt, but should still take accessibility seriously.

Austrian law: Web Accessibility Act (WZG)

In Austria, the Web Accessibility Act (WZG) also applies, which implements EU Directive 2016/2102. It obliges all public bodies to have accessible websites and apps that comply with WCAG 2.1 Level AA. This includes:

• Federal, state and local authorities
• Public companies (e.g., ÖBB, Wiener Linien)
• Publicly funded institutions
• All websites and mobile applications of these places

Sanctions:Complaints can be submitted to the relevant arbitration body. Violations may result in administrative penalties.

Germany: Accessibility Strengthening Act (BFSG)

The German Federal Training Assistance Act (BFSG) implements the EAA and has been in effect since June 28, 2025. For the first time, it extends the obligation for accessibility to the private sector. This is particularly relevant for Austrian companies that also sell in Germany: online shops and digital services must comply with WCAG 2.1 Level AA.

Consequences of non-compliance

• Warnings:Consumer protection associations and affected individuals can file lawsuits.
• Fines:Up to €100,000 in Germany, similar amounts in Austria
• Reputational damage:Public criticism from disability organizations and the media
• Competitive disadvantage:Public sector clients are increasingly demanding proof of accessibility.
• Loss of revenue:Excluding 15–20% of the population with disabilities as potential customers

WCAG 2.2: The current standard

The Web Content Accessibility Guidelines (WCAG) are the internationally recognized standard for accessible websites, developed by the World Wide Web Consortium (W3C). The current version, WCAG 2.2, was published in October 2023 and introduces nine new success criteria.

The three levels of conformity

Level A (Minimum):Basic accessibility. If these criteria are not met, certain user groups are completely excluded. Examples: alternative text for images, keyboard accessibility, no information based solely on color.

Level AA (Recommended and legally required):The standard required by laws such as the WZG and the EAA. It includes Level A plus additional requirements such as sufficient contrast (4.5:1), text scaling up to 200%, and consistent navigation.

Level AAA (Optimal):The highest standard. In practice, full AAA compliance for entire websites is hardly achievable, but individual criteria should be implemented where possible. Examples: 7:1 contrast ratio, sign language videos, extended audio descriptions.

New criteria in WCAG 2.2

WCAG 2.2 brings important additions:

• 2.4.11 Focus Not Obscured (Minimum):The focus indicator of an element must not be completely obscured (e.g., by a sticky header).
• 2.4.12 Focus Not Obscured (Enhanced):The focus indicator must not be obscured at all.
• 2.4.13 Focus Appearance:The focus indicator must have a certain minimum size and minimum contrast.
• 2.5.7 Dragging Movements:Functions that require dragging movements must also be operable without dragging.
• 2.5.8 Target Size (Minimum):Interactive elements must be at least 24×24 CSS pixels in size.
• 3.2.6 Consistent Help:Help mechanisms must be consistently placed.
• 3.3.7 Redundant Entry:Information that has already been entered must not be requested again.
• 3.3.8 Accessible Authentication (Minimum):Authentication must not require cognitive function tests.
• 3.3.9 Accessible Authentication (Enhanced):Extended requirements for accessible authentication.

The 4 POUR principles of accessibility

WCAG is based on four fundamental principles known as POUR. Every success criterion is subordinate to one of these principles.

1. Perceivable

Information and user interface components must be presented in a way that allows all users to perceive them. A blind user cannot see images – therefore, they need alternative text. A deaf user cannot hear audio – therefore, they need subtitles.

Key demands:

• Alternative text for all non-textual content (images, icons, graphics)
• Subtitles and transcripts for audio and video content
• Content can be displayed in various ways (e.g., without loss of information when enlarged)
• Sufficient contrast between text and background
• Do not use text as an image (except for logos)

2. Operable (Operable)

All navigation elements and interaction options must be accessible to all users. Those who cannot use a mouse must be able to operate the website entirely via keyboard. Users who need more time must not be excluded by time limits.

Key demands:

• Full keyboard accessibility (Tab, Enter, Escape, arrow keys)
• No keyboard trap (user must not be "trapped" in an element)
• Sufficient time for interactions (timer can be paused or extended)
• No content that triggers seizures (no flashing lights above 3 Hz)
• Clear, consistent navigation and orientation
• Visible focus indicator during keyboard navigation

3. Understandable

Information and user interface operation must be understandable. The language must be clear, the navigation predictable, and errors must be avoided or explained clearly.

Key demands:

• The language of the page is defined in the HTML (lang="de")
• Foreign language passages marked
• Navigation is consistent across all pages.
• Form fields are labeled and error messages are understandable.
• Help and error prevention when entering data

4. Robust

Content must be robust enough to be reliably interpreted by different user agents (browsers, screen readers, alternative input devices).

Key demands:

• Valid HTML (correct nesting, unique IDs)
• ARIA roles and attributes used correctly
• Status messages are available programmatically.
• Compatibility with current and future technologies

Practical implementation: step by step

Theory is important, but practice is what counts. In this section, we'll show you specifically how to implement the most important accessibility requirements. An accessible website starts with...UX designand continues to develop.

Contrasts and colors

The most common accessibility error: Insufficient contrast. According to a WebAIM study, 83% of all websites have contrast problems. The WCAG requirements:

Tools for contrast testing:

• WebAIM Contrast Checker (online)
• Color Contrast Analyzer (Desktop App)
• Chrome DevTools (Accessibility Inspector)

Practical tips:

• Never use color as the sole distinguishing feature (e.g., additionally mark red error messages with an icon or text).
• Placeholder text in forms often lacks sufficient contrast – use visible labels instead.
• Offer a dark mode, but also pay attention to contrasts.
• Links within running text should be indicated not only by color, but also by underlining.

Alternative text for images

Every image needs alt text – but not every alt text has to be descriptive:

Informative images:Alt text describes the content and purpose. Use "Chart showing 35% revenue growth in Q3 2025" instead of "Chart" or "chart.png".

Decorative images:Empty alt text (alt="") so that screen readers skip the image. Applies to background patterns, separator lines, and purely decorative elements.

Functional images (links, buttons):Alt text describes the function, not the image. Use "Homepage" instead of "Logo" for a linked logo.

Complex images (diagrams, infographics):Short alt text plus detailed description in the surrounding text or via aria-describedby.

SVG icons:Use `aria-label` or `title` within the SVG element. Hide decorative icons with `aria-hidden="true"`.

Keyboard accessibility

Many users cannot use a mouse and navigate exclusively via keyboard. Test your website by putting the mouse away and navigating only with the keyboard:

Basic keyboard controls:

• Tab:Jump to the next interactive element
• Shift+Tab:Go to previous element
• Enter:Activate link or button
• Spacebar:Toggle checkbox, activate button
• Arrow keys:Navigating within menus, tabs, and radio buttons
• Escape:Close modal/dropdown

Focus Management:

• Every interactive element must have a visible focus indicator.
• The tab order must be logical (follows the DOM, not the visual layout)
• With modals, the focus must be trapped within the modal.
• After closing a modal, the focus must return to the triggering element.

Common problems:

• Custom dropdowns without keyboard control
• Sliders/carousels cannot be operated with arrow keys.
• Hamburger menus that cannot be opened via keyboard
• Focus jumps to the top of the page after modal closure.
• Outline removed (outline: none) without alternative

Using ARIA correctly

ARIA (Accessible Rich Internet Applications) extends HTML with attributes that improve the accessibility of dynamic content. But beware: Incorrectly used ARIA does more harm than good.

ARIA's first rule:Do not use ARIA if a native HTML element serves the same purpose. A button element does not need a role="button". A nav element does not need a role="navigation".

Key ARIA attributes:

• aria-label:Labels for elements without visible text (e.g., icon buttons)
• aria-labelledby:Link one element to another element as a label
• aria-describedby:Additional description (e.g. form help texts)
• aria-hidden="true":Hide decorative elements from screen readers
• aria-expanded:Indicates whether a hinged element is open or closed.
• aria-live:Defines live regions that will be read aloud when changes are made.
• role:Defines the role of an element (e.g., role="alert", role="tabpanel")

Example – accessible accordion:

<h3> <button aria-expanded="false" aria-controls="section1"> Section 1 </button> </h3> <div id="section1" role="region" hidden> <p>Contents of Section 1</p> </div>

Designing accessible forms

Forms are often the biggest hurdle for users with disabilities. Accessible forms require:

Labels:Every input field needs a visible, programmatically linked label (label for="id"). Placeholder text is NOT a substitute for labels.

Error messages:Errors must be clearly described (not just "Error in field 3", but "Please enter a valid email address"). Error messages must be programmatically linked to the field (aria-describedby).

Groups:Group related fields using fieldset and legend (e.g., address fields, radio buttons).

Validation:Client-side validation using aria-invalid and aria-describedby. Error summary at the beginning of the form with links to the erroneous fields.

Autocomplete:Use the autocomplete attribute so that browsers and password managers can automatically fill in fields.

Responsive design and accessibility

Accessibility and responsive design complement each other perfectly. Important points related toCore Web Vitalsand performance:

• Text must be scalable up to 200% without horizontal scrolling.
• Touch targets must be at least 44×44 px in size (WCAG recommends 48×48 px)
• Pay attention to the spacing between touch targets (min. 8 px)
• Content must not be cut off or overlaid when zooming or enlarging.
• Media queries for prefers-reduced-motion and prefers-color-scheme are supported.

Accessibility testing tools

Accessibility cannot be guaranteed solely through automated tools – but they are an important starting point. Also, take advantage of ourWebsite Design Analyzeras a first check.

Automated testing tools

Manual tests

Automated tools only find about 30% of accessibility problems. The following manual tests are essential:

Keyboard test:Navigate your entire website using only the keyboard. Can you access and use all functions? Is the focus indicator always visible? Are there any keyboard traps?

Screen reader test:Test with NVDA (Windows, free), VoiceOver (macOS/iOS, integrated), or JAWS (Windows, commercial). Is all content read aloud correctly? Are images described? Are forms usable?

Zoom test:Zoom in to 200% and 400%. Is everything legible? Are any elements overlapping? Is any content disappearing?

Cognitive tests:Is the language understandable? Are the instructions clear? Can mistakes be easily corrected? Is the navigation consistent?

User testing with people with disabilities

The most informative testing method: Invite people with various disabilities to test your website. Organizations like MAIN (Medienarbeit Integrativ) in Austria connect you with testers with disabilities. These tests uncover problems that no automated tool or able-bodied developer can find.

Accessibility and SEO: The perfect synergy

Accessibility and search engine optimization are natural allies. Many accessibility measures simultaneously improve Google rankings. Why? Because search engine bots "read" websites much like screen readers – they can't see images, watch videos, or interpret JavaScript (or only to a limited extent).

Overlaps between Accessibility and SEO

Specific advantages

Lower bounce rate:Accessible websites are more user-friendly. Users find what they're looking for faster and stay longer. Google considers this a positive user signal.

Larger target audience:15–20% of the population has a disability. An accessible website appeals to this target group and generates more traffic, more conversions, and more revenue.

Improved technical quality:Valid HTML, correct heading hierarchy and semantic markup are essential for both accessibility and SEO.

Voice Search:Accessible websites are better optimized for voice search because they offer clear, structured content that voice assistants can interpret.

Common mistakes during implementation

In our experience at GoldenWing, we see these errors time and again – even on websites that are supposed to be “accessible”:

Top 10 Accessibility Mistakes

1. Missing or meaningless alt text:“Image1.jpg” or “DSC_4023” are not alt text. Equally unhelpful are alt texts that only repeat the keyword without describing the image.

2. Insufficient contrast:Especially with modern, minimalist designs featuring light gray tones on a white background. Design and accessibility are not mutually exclusive – they simply require conscious design.

3. Lack of keyboard accessibility:Custom components (dropdown menus, tabs, modals) without keyboard control. This is especially common in JavaScript frameworks that replace native HTML elements with divs and spans.

4. Outline removed:CSS outline: none on :focus without alternative. The focus indicator is essential for keyboard users. Never remove it without providing an equivalent replacement.

5. Autoplay media:Videos and audio that start automatically are not only annoying, but particularly problematic for screen reader users.

6. PDFs are not accessible:The website itself can be perfectly accessible – but if the linked PDFs are not, a significant barrier remains.

7. CAPTCHAs without alternative:Traditional CAPTCHAs are unusable for many users. Use accessible alternatives such as hCaptcha Accessibility or invisible CAPTCHAs.

8. Dynamic content without ARIA Live Regions:Shopping cart updates, error messages, and loading instructions are not announced by screen readers if aria-live is missing.

9. Missing skip links:Keyboard users have to tab through the entire navigation on every page before reaching the main content. A "Skip to main content" link solves this problem.

10. Language not defined:The lang attribute is missing in the HTML, causing screen readers to use the incorrect pronunciation.

Costs and effort

A frequently asked question: What does accessibility cost? The answer depends heavily on whether you are retrofitting an existing website or developing a new website with accessibility in mind from the outset.

Develop a new, accessible website

Additional costs compared to a non-accessible website:10–20%. The effort lies mainly in the planning, semantic development, and testing. If accessibility is considered from the outset, the additional effort is manageable.

Upgrade existing website

Cost:20–50% of the original development costs. Retrofitting is always more expensive than developing from scratch because existing code has to be rewritten, designs adapted, and content revised. An accessibility audit identifies the most critical barriers as a starting point.

Ongoing costs

• Regular audits:1-2 times a year, €1,500-€5,000
• Content creation:Alt text, subtitles, accessible PDFs – ongoing effort
• Training:Training staff in editorial, design and development
• Monitoring tools:€100–500/month for automated monitoring

ROI of accessibility

Investing in accessibility pays off:

• 15–20% larger target group(People with disabilities)
• Better SEO ranking(see synergies above)
• Lower bounce rate(better user experience)
• Legal certainty(Avoidance of fines and warnings)
• Positive brand image(social responsibility)

Checklist: Accessible Website

This checklist summarizes the most important points:

Noticeable:

• All images have descriptive alt text.
• Videos have subtitles and/or transcripts.
• Contrast meets WCAG AA (4.5:1 for normal text)
• Color is never the only distinguishing feature.
• Text can be enlarged up to 200%.

Operable:

• All functions are accessible via keyboard.
• Focus indicators are visible
• Skip links are available.
• No keyboard traps
• Time limits are customizable.

Understandable:

• Page language is defined (lang="de")
• Navigation is consistent
• Forms have visible labels and understandable error messages.
• The content is written clearly and understandably.

Robust:

• HTML is valid
• ARIA is being used correctly
• Website works with current screen readers
• Dynamic content uses aria-live

If you need support with making your website accessible,contact our teamGoldenWing offers accessibility audits, training, and the implementation of accessible websites from a single source.

Frequently Asked Questions (FAQ)

Does my website need to be accessible?

Since June 2025, the European Accessibility Act (EAA) has required many private companies to make their digital offerings accessible. This particularly affects e-commerce, financial services, and telecommunications – with the exception of micro-enterprises with fewer than 10 employees AND an annual turnover of less than €2 million. Public bodies in Austria have been obligated to do so since the Accessibility Act (WZG). Even if you are not legally required to be accessible, accessibility is worthwhile from both an economic and ethical perspective.

How much does an accessibility audit cost?

A professional WCAG 2.2 audit costs between €1,500 and €8,000, depending on the size of the website. A basic audit for a company website with 10–30 pages typically costs between €2,000 and €3,500 and includes automated tests, manual review, and a detailed, prioritized list of recommended actions. At GoldenWing, we offer audits starting at €2,500.

Is an automated accessibility testing tool sufficient?

No, automated tools like axe or WAVE only find about 30% of accessibility problems. While they detect missing alt text or contrast errors, they can't assess whether alt text is meaningful, whether the tab order is logical, or whether a screen reader user understands the context. Automated tests are an important starting point, but manual testing and, ideally, user testing with people with disabilities are essential.

Is accessibility a one-off project or an ongoing process?

Accessibility is an ongoing process. Every new piece of content (images, videos, PDFs), every design update, and every new feature must be checked for accessibility. We recommend regular audits (at least annually), automated monitoring tools for continuous tracking, and training for all employees who create content or develop the website.

Does accessibility harm the design.

A widespread myth. Accessibility and appealing design are not mutually exclusive – quite the opposite. Many of the most successful websites (Apple, BBC, GOV.UK) are prime examples of accessible AND aesthetically pleasing design. The key lies in conscious design: sufficient contrast, clear typography, and well-thought-out interaction patterns improve the design for all users, not just people with disabilities.

How long does it take to make an existing website accessible?

This depends on the initial state and complexity. For a typical corporate website with 20–50 pages, plan for 4–8 weeks for an audit plus implementation of critical measures. Full WCAG-AA compliance can take 2–4 months for complex websites with many interactive elements. We recommend a phased approach: first eliminate the most critical barriers (Level A), then gradually expand to Level AA.

Using ARIA attributes correctly: A practical guide

ARIA (Accessible Rich Internet Applications) is a powerful tool for making web applications accessible to screen readers and other assistive technologies. However, ARIA is frequently misused, which worsens rather than improves accessibility.

The golden rule: No ARIA is better than a false ARIA.

Before using ARIA attributes, always check if anative HTML elementIt fulfills the same function. A '<button>' is always better than a '<div role="button">'. Native elements automatically include keyboard accessibility, focus management, and screen reader support.

The most important ARIA roles for modern websites

Landmark RollsStructure your page for screen reader users:

• 'role="banner"' -- corresponds to '<header>', the header area of the page
• 'role="navigation"' -- corresponds to '<nav>', navigation areas
• 'role="main"' -- corresponds to '<main>', the main content
• 'role="contentinfo"' -- corresponds to '<footer>', the footer area
• 'role="complementary"' -- corresponds to '<aside>', complementary content

A notice:If you are using semantic HTML5 elements, these roles are redundant. Only use them if you cannot use semantic elements for technical reasons.

ARIA States and Properties in Practice

aria-expanded:For expandable menus, accordions, and dropdown menus:

• Set 'aria-expanded="false"' in the closed state
• Change to 'aria-expanded="true"' when opening
• Connect the controlling element to the controlled area via 'aria-controls'

aria-live:For dynamic content changes (notifications, status messages):

• 'aria-live="polite"' -- Change will be announced when the user is inactive (default for most cases)
• 'aria-live="assertive"' -- Change will be announced immediately (only for critical messages such as error messages)

aria-label and aria-labelledby:For elements that have no visible text:

• 'aria-label="Close main navigation"' for icon buttons
• 'aria-labelledby="section-heading"' to link an element with a visible heading

Common ARIA errors and their correction

• Redundant roles:'<nav role="navigation">' is redundant. Simply use '<nav>'.
• Lack of keyboard access:Adding a `role="button"` to a `<div>` does not automatically make it keyboard-compatible. You need to add `tabindex="0"` and a keyboard event handler.
• aria-hidden="true" on visible content:Hides content from screen readers, even though it is visible.
• Missing Live Regions:Dynamic error messages in forms without 'aria-live' are not recognized by screen readers.

Testing workflow for ARIA implementations

1. Automated testing:axe DevTools or Lighthouse identify basic ARIA errors
2. Screen reader test:Test with NVDA (Windows, free) or VoiceOver (macOS, pre-installed)
3. Keyboard navigation:Test each interactive area using only the keyboard.
4. Browser DevTools:The accessibility panels in Chrome and Firefox display the calculated ARIA tree.

Accessible forms and interactive elements

Forms are one of the most critical areas for accessibility. In Austria, around18% of the populationAssistive technologies – these are potential customers you lose due to inaccessible forms.

Basic rules for accessible forms

Correctly link labels and input fields:

Each input field requires a uniquely assigned label. The link is established via the 'for' attribute on the label and the corresponding 'id' on the input field. Placeholder text isnoA substitute for a label -- it disappears upon input and does not provide a reliable label.

Making error messages accessible:

• Error messages mustprogrammaticbe linked to the faulty field (via 'aria-describedby')
• Use 'aria-invalid="true"' for invalid fields.
• Place error messagesin front of or next tothe field, not just at the beginning of the form
• Focus on the first error message after submission.

Logically structure field groups:

• Use '<fieldset>' and '<legend>' for related fields (e.g., address details, payment information)
• Radio buttons and checkboxes always belong in a field group.

Accessible custom components

Dropdown menus / Select alternatives:

• Use the native '<select>' element whenever possible.
• For custom dropdowns: Implement the full WAI-ARIA Combobox specification.
• Keyboard controls: Arrow keys to navigate, Enter to select, Escape to close.

Datepicker:

• Native '<input type="date">' is the most accessible option
• Custom datepickers must be fully operable via keyboard.
• Always offer manual text input as an alternative.

Slider / Range inputs:

• Use '<input type="range">' where possible
• For custom sliders: implement 'role="slider"', 'aria-valuemin', 'aria-valuemax', 'aria-valuenow' and 'aria-valuetext'

Designing accessible multi-step forms

For longer forms (e.g., checkout processes), additional requirements apply:

• Progress indicator:Use 'aria-current="step"' for the current step
• Step-by-step navigation:Enable the return to previous steps using the keyboard.
• Received input:Fields that have already been filled in must be retained when navigating back.
• Summary:Provide an accessible summary of all entries before final submission.

Accessibility for e-commerce: Making online shops accessible

From theJune 28, 2025The Accessibility Strengthening Act (BaFG) comes into force in Austria, implementing the EU directive European Accessibility Act (EAA). Online shops are directly affected.

Legal requirements for Austrian online shops

The BaFG applies toall companies except micro-enterprises(fewer than 10 employees and less than EUR 2 million annual turnover). Affected online shops must:

• The WCAG 2.1 Compliance Level AA retain
• A Accessibility Statementpublish
• A Feedback mechanismprovide solutions for accessibility issues
• Violations may result in administrative fines of up to...EUR 80,000

Critical areas in e-commerce

Product pages:

• All product images need meaningful alt text (not just "product image", but "blue men's polo shirt, size M, made of organic cotton")
• Size and color selectors must be operable via keyboard.
• Price information must not only be communicated visually (e.g., crossed-out price).

Shopping cart and checkout:

• Quantity changes and delete functions must be operable via keyboard and screen reader.
• Implement status messages ("Article added") as 'aria-live' regions
• Payment forms must be fully accessible -- including credit card input fields.

Filter navigation:

• Faceted filters must be operable via keyboard.
• Filter changes must be announced dynamically ('aria-live')
• The number of results after filtering must be communicated.

Search:

• Autocomplete suggestions must be navigable via keyboard.
• Search results must be announced as a live region.
• "No results" messages must be recognized by screen readers.

Accessibility audit for existing shops

Conduct a structured audit in four phases:

1. Automated scanning:Tools like axe, WAVE, or Lighthouse identify approximately 30-40% of all accessibility problems.
2. Manual testing:Keyboard navigation through all critical user flows (search, product selection, shopping cart, checkout)
3. Assistive Technology Testing:Screen reader tests with NVDA/VoiceOver and magnification software
4. User testing:Tests with affected individuals -- at least 3-5 people with different disabilities

ROI of accessible online shops

Accessibility is not only a legal obligation, but also makes economic sense:

• 15-20% of the populationhave some form of disability -- a significant customer group
• Accessible shops achieve an average of12% higher conversion rates(better usability for everyone)
• SEO benefits:Accessible websites tend to rank better (clean markup, alt text, semantic HTML)
• Reduced legal risk:Avoidance of warnings and administrative penalties

Create and maintain an accessibility statement

An accessibility statement will be mandatory for most Austrian websites and online shops from June 2025. It documents the current state of accessibility and shows your users that you take the issue seriously.

Legal basis and requirements

The Accessibility Strengthening Act (BaFG) and the Web Accessibility Act (WZG) in Austria require companies to publish an accessibility statement. This statement must:

• Found on every websitebe (ideally linked in the footer)
• In simple languagebe written
• Regularly updatedwill be (at least annually)
• Contact informationincluded for feedback

Mandatory content of an accessibility statement

1. Scope:

Describe which website(s) or app(s) the statement applies to. Provide the exact URLs.

2. Conformity status:

Choose one of the following formulations:

• "Fully Compliant" -- all WCAG 2.1 AA criteria are met
• "Partially compliant" -- most, but not all, criteria are met.
• "Non-compliant" -- essential criteria are not met.

In practice, most websites are "partially compliant." Be honest here—a transparent statement is better than a false one.

3. Known limitations:

List specifically which areas are not fully accessible:

• "Videos currently do not contain subtitles (correction planned by Q3 2026)"
• "The date picker in the booking function is not fully operable via keyboard."
• "PDF documents from the period before 2024 are not accessible"

4. Feedback mechanism:

Provide a clear communication channel:

• Dedicated email address (e.g., accessibility@company.at)
• Contact form (which itself must be accessible)
• Phone number as an alternative

5. Enforcement procedure:

Refer to the responsible authority in Austria: theAustrian Research Promotion Agency (FFG)as a complaints office for digital accessibility.

Template for an accessibility statement

Use theGenerator of the EU CommissionUse it as a starting point and adapt it to your specific situation. The W3C also offers a comprehensive template on the WAI website.

Maintenance and updates

• After every website relaunch:Completely revise the statement
• Quarterly:Update known restrictions
• Following accessibility audits:Document results and measures
• Regarding user feedback:Record reported problems and specify the resolution timeframe.

Best practices from the DACH region

Exemplary accessibility statements can be found at:

• oesterreich.gv.at:Very detailed with concrete measures and timelines
• Deutsche Bahn (bahn.de):Transparent communication of known limitations
• Vienna Public Transport (wienerlinien.at):Clear structure with contact options

Use these examples as a guide and adjust the level of detail to the size and complexity of your website. A well-maintained accessibility statement signals professionalism and a sense of responsibility—values that your sighted and hearing customers will also appreciate.

Accessibility in redesign: Retrofitting existing websites

Many Austrian companies face the challenge of making their existing websites accessible without having to completely rebuild the entire project. With the Accessibility Strengthening Act (BaFG), which comes into effect in June 2025, retrofitting is no longer an option for numerous businesses, but a legal obligation. The good news: A systematic approach makes retrofitting manageable and cost-effective.

Inventory: Where does your website currently stand?

Before you begin the retrofit, you need an honest analysis of the current situation. Use a combination of automated and manual tests:

• Automated scansTools like axe DevTools, WAVE or Lighthouse uncover approximately 30–40 percent of all barriers – primarily missing alt text, insufficient color contrast and faulty ARIA attributes.
• Manual keyboard navigationNavigate your entire website using only the keyboard. Can you reach every interactive element? Is the focus always visible?
• Screen reader testsHave your pages read aloud using VoiceOver (macOS/iOS) or NVDA (Windows). Does the order in which the text is read make sense? Are images and forms described correctly?
• Content auditCheck texts for comprehensibility, heading structure, and correct language markup.

Document each barrier encountered in a structured list withSeverity(critical, serious, moderate, minor)Affected page type and WCAG success criterionThis list will be your roadmap for retrofitting.

Prioritization: The correct order of actions

Not all barriers have the same urgency. Prioritize according to...Impact-Effort Principle:

Implement immediately (quick wins with high impact):

• Adding missing alt text for images – this often affects hundreds of images and is nevertheless relatively quick to implement.
• Adjusting color contrasts – often small adjustments in the CSS file are sufficient.
• Adding missing form labels – technically simple, but extremely important for screen reader users.
• Incorporate skip navigation links – a single component that helps all keyboard users.

Implement in the medium term (moderate complexity):

• Correcting the heading hierarchy requires adjustments to templates and existing content.
• Correctly setting ARIA landmarks and roles requires technical understanding but massively improves page structure.
• Revise focus management for dynamic content (modals, accordions, tabs) – JavaScript adjustments required.
• Ensure responsive behavior for Zoom up to 200 percent

Long-term planning (high effort):

• Complete redesign of interactive components such as custom dropdowns, date pickers or carousels.
• Add subtitles and transcripts to video and audio content
• Make PDF documents accessible or replace them with HTML alternatives.
• Making complex data visualizations accessible

Technical Retrofitting: Step by Step

In the technical implementation, acomponent-based approachProven. Instead of going through page by page, identify the reused components of your website and make them accessible individually:

Header and navigationNavigation is the most frequently used element of your website. Ensure that the menu is keyboard-operable, submenus can be closed with the Escape key, and the current page area is marked with `aria-current="page"`. For mobile hamburger menus, focus must jump to the menu when opened and return to the trigger when closed.

Forms and contact pagesEach input field requires a programmatically linked label. Error messages must be recognizable both visually and by screen readers – use `aria-describedby` for error texts and `aria-invalid="true"` for invalid fields. Mark required fields not only with an asterisk but also with `aria-required="true"`.

Content areasEnsure all headings form a logical hierarchy (H1 → H2 → H3, without jumps). Lists use the correct HTML elements (`ul`, `ol`, `dl`). Links are clearly labeled – 'Learn more' without context is useless for screen reader users.

CMS adjustments for editorial accessibility

Technical upgrades are only half the battle. To ensure future content remains accessible, you need to adapt your content management system:

• Alt text as a required fieldConfigure – no image upload without alternative text
• Heading Templatespredefine a correct hierarchy
• Editorial guidelinesCreate with clear specifications for link labels, table structure and document formats.
• Automated checksIntegrate into the CMS to report contrast violations or missing labels before publication.

Plan costs and timeframe realistically

For a typical Austrian company website with 30–80 pages, you should expect the following effort:

• Audit and inventory2–4 working days
• Implementing Quick Wins3–5 working days
• Component-based retrofitting10–20 working days, depending on complexity
• Content post-processing5–10 working days (highly dependent on the scope)
• Testing and fine-tuning3–5 working days

Overall, the costs for a professional retrofit range between5,000 and 25,000 euros– significantly cheaper than a complete redesign, which can quickly cost three to five times as much. The crucial point is that you don't view the retrofit as a one-off measure, but rather integrate it into your ongoing quality assurance process.

Conclusion: Accessibility is not an obstacle, but an opportunity.

Website accessibility according to WCAG 2.2 will no longer be optional by 2026, but mandatory – legally, economically, and ethically. Companies that invest now will benefit from a larger target audience, improved SEO, lower bounce rates, and a positive brand image. The costs are manageable, and the return on investment is measurable.

GoldenWing has been supporting Austrian companies on their journey to accessible websites for over three years. From initial analysis and concept development to technical implementation and ongoing maintenance, we offer everything from a single source.Contact usfor a free initial consultation and find out how accessible your website currently is.

Accessible web design by experts: Web Design Vienna — accessible and WCAG compliant.