Website accessibility (WCAG): the guide for 2026

Website accessibility (WCAG): the complete guide 2026

Accessibility on the web is no longer an optional nice to have, it is a legal duty, an ethical responsibility and a tangible business advantage. Around 1.4 million people with a disability live in Austria, across Europe there are more than 87 million. On top of that come millions of older users and people with temporary limitations. An accessible website reaches all of these people, and at the same time it offers a better user experience for every single visitor.

At GoldenWing we have been building accessible websites for more than 3 years and we know the challenges, the legal requirements and the practical solutions. In this comprehensive guide you will find 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 ability. That includes people with:

• Visual impairments: blindness, low vision, colour blindness
• Hearing impairments: deafness, hardness of hearing
• Motor limitations: limited fine motor skills, paralysis, tremor
• Cognitive limitations: learning disabilities, ADHD, autism, dementia
• Temporary limitations: a broken arm, an eye infection, a noisy environment
• Situational limitations: sunlight on the screen, one handed use on the bus

The curb cut effect

Urban planning knows the "curb cut effect": dropped kerbs were introduced for wheelchair users, but they are used just as much by parents with prams, couriers with trolleys and cyclists. Exactly the same thing happens on the web: accessible websites are easier for EVERYONE to use.

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 for power users too. Accessibility is not a special case, it is good web design.

Legal requirements: the EU, Austria and the DACH region

The legal requirements for accessible websites have tightened massively in recent years. Companies that do not act now risk cease and desist letters and serious penalties.

The European Accessibility Act (EAA)

The European Accessibility Act (directive (EU) 2019/882) has been binding in all EU member states since 28 June 2025. It obliges companies that offer digital products and services to make them accessible. Among those affected are:

• Ecommerce websites and online shops
• Banking services and financial products
• Telecommunications services
• Ebooks and ereaders
• Passenger transport services
• Products with a digital interface

Important: The EAA does not only concern large corporations. SMEs from 10 employees or 2 million euros of annual revenue also fall under the rules. Micro enterprises are exempt, but they should take accessibility seriously nonetheless.

Austrian law: the Web Accessibility Act (WZG)

In Austria the Web Accessibility Act (Web-Zugänglichkeits-Gesetz, WZG) applies in addition, implementing EU directive 2016/2102. It obliges all public bodies to provide accessible websites and apps to WCAG 2.1 level AA. That covers:

• Federal, state and municipal authorities
• Public companies (ÖBB and Wiener Linien, for example)
• Institutions financed by public bodies
• All websites and mobile applications of these bodies

Sanctions: Complaints can be filed with the responsible conciliation body. Breaches risk administrative penalties.

Germany: the Accessibility Strengthening Act (BFSG)

The German BFSG implements the EAA and has applied since 28 June 2025. For the first time it extends the duty of accessibility to the private sector. This is particularly relevant for Austrian companies that also sell in Germany: online shops and digital services have to meet WCAG 2.1 level AA.

The consequences of non compliance

• Cease and desist letters: Consumer protection associations and affected people can sue
• Fines: Up to 100,000 euros in Germany, similar amounts in Austria
• Reputational damage: Public criticism from disability associations and the media
• A competitive disadvantage: Public sector clients increasingly ask for proof of accessibility
• Lost revenue: Excluding the 15 to 20 percent of the population with disabilities as potential customers

WCAG 2.2: the current standard

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

The three conformance levels

Level A (minimum): Basic accessibility. If these criteria are not met, certain groups of users are locked out completely. Examples: alternative text for images, keyboard accessibility, no information conveyed by colour alone.

Level AA (recommended and required by law): The standard that laws such as the WZG and the EAA demand. It covers level A plus additional requirements such as sufficient contrast (4.5:1), text scaling up to 200 percent and consistent navigation.

Level AAA (optimal): The highest standard. In practice full AAA conformance is hardly achievable for entire websites, but individual criteria should be implemented wherever possible. Examples: a contrast ratio of 7:1, sign language videos, extended audio description.

The 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 hidden (by a sticky header, for example).
• 2.4.12 Focus Not Obscured (Enhanced): The focus indicator must not be hidden at all.
• 2.4.13 Focus Appearance: The focus indicator has to have a certain minimum size and minimum contrast.
• 2.5.7 Dragging Movements: Functions that require a dragging movement have to be operable without dragging too.
• 2.5.8 Target Size (Minimum): Interactive elements have to be at least 24 by 24 CSS pixels.
• 3.2.6 Consistent Help: Help mechanisms have to be placed consistently.
• 3.3.7 Redundant Entry: Information already entered must not be asked for again.
• 3.3.8 Accessible Authentication (Minimum): Authentication must not require a cognitive function test.
• 3.3.9 Accessible Authentication (Enhanced): Extended requirements for accessible authentication.

The 4 POUR principles of accessibility

WCAG rests on four fundamental principles known as POUR. Every success criterion belongs to one of these principles.

1. Perceivable

Information and user interface components have to be presented so that all users can perceive them. A blind user cannot see images, so they need alternative text. A deaf user cannot hear audio, so they need subtitles.

Core requirements:

• Alternative text for all non text content (images, icons, graphics)
• Subtitles and transcripts for audio and video content
• Content presentable in different ways (without loss of information when enlarged, for example)
• Sufficient contrast between text and background
• Not using text as an image (except for logos)

2. Operable

All navigation elements and ways of interacting have to be operable by all users. Anyone who cannot use a mouse has to be able to operate the website entirely by keyboard. Anyone who needs more time must not be locked out by time limits.

Core requirements:

• Full keyboard accessibility (tab, enter, escape, arrow keys)
• No keyboard trap (the user must not be "caught" inside an element)
• Enough time for interactions (timers that can be paused or extended)
• No content that triggers seizures (no flashing above 3 Hz)
• Clear, consistent navigation and orientation
• A visible focus indicator during keyboard navigation

3. Understandable

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

Core requirements:

• The language of the page defined in the HTML (lang="de")
• Passages in another language marked up
• Navigation consistent across all pages
• Form fields labelled and error messages understandable
• Help and error prevention during input

4. Robust

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

Core requirements:

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

Practical implementation: step by step

Theory matters, but practice decides. In this section we show you concretely how to implement the most important accessibility requirements. An accessible website starts with UX design and continues through development.

Contrast and colour

The most frequent accessibility error: insufficient contrast. According to the WebAIM study, 83 percent of all websites have contrast problems. The WCAG requirements:

Tools for checking contrast:

• WebAIM Contrast Checker (online)
• Colour Contrast Analyser (desktop app)
• Chrome DevTools (accessibility inspector)

Practical tips:

• Never use colour as the only distinguishing feature (mark red error messages with an icon or text as well, for example)
• Placeholder text in forms often has too little contrast, rely on visible labels
• Offer a dark mode, but watch the contrast there too
• Mark links inside body text not only by colour but also by underlining

Alternative text for images

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

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

Decorative images: An empty alt text (alt=""), so screen readers skip the image. This applies to background patterns, dividers and purely decorative elements.

Functional images (links, buttons): The alt text describes the function, not the image. "To the home page" instead of "logo" for a linked logo.

Complex images (charts, infographics): A short alt text plus a detailed description in the surrounding text or through aria-describedby.

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

Keyboard accessibility

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

Basic keyboard control:

• Tab: Jump to the next interactive element
• Shift+Tab: To the previous element
• Enter: Activate a link or button
• Space: Toggle a checkbox, activate a button
• Arrow keys: Navigate inside menus, tabs and radio buttons
• Escape: Close a modal or dropdown

Focus management:

• Every interactive element has to have a visible focus indicator
• The tab order has to be logical (it follows the DOM, not the visual layout)
• In modals the focus has to be trapped inside the modal (a focus trap)
• After a modal is closed the focus has to return to the triggering element

Frequent problems:

• Custom dropdowns without keyboard control
• Sliders and carousels that cannot be operated with the arrow keys
• Hamburger menus that cannot be opened by keyboard
• Focus jumping to the top of the page after a modal closes
• The outline removed (outline: none) without an alternative

Using ARIA correctly

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

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

Important ARIA attributes:

• aria-label: A label for elements without visible text (icon buttons, for example)
• aria-labelledby: Links an element to another element as its label
• aria-describedby: An additional description (form help text, for example)
• aria-hidden="true": Hides decorative elements from screen readers
• aria-expanded: Indicates whether an expandable element is open or closed
• aria-live: Defines live regions that are read out when they change
• role: Defines the role of an element (role="alert" or role="tabpanel", for example)

An example, an accessible accordion:

<h3> <button aria-expanded="false" aria-controls="section1"> Section 1 </button> </h3> <div id="section1" role="region" hidden> <p>The content 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 label linked programmatically (label for="id"). Placeholder text is NOT a substitute for a label.

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

Groups: Group related fields with fieldset and legend (address fields or radio buttons, for example).

Validation: Client side validation with aria-invalid and aria-describedby. An error summary at the top of the form with links to the fields that failed.

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

Responsive design and accessibility

Accessibility and responsive design complement each other perfectly. Important points in connection with Core Web Vitals and performance:

• Text has to be enlargeable to 200 percent without horizontal scrolling
• Touch targets have to be at least 44 by 44 px (WCAG recommends 48 by 48 px)
• Mind the spacing between touch targets (at least 8 px)
• Content must not be cut off or overlapped when zoomed or enlarged
• Support the media queries prefers-reduced-motion and prefers-color-scheme

Testing tools for accessibility

Accessibility cannot be ensured by automated tools alone, but they are an important starting point. Use our website design analyzer as a first check as well.

Automated testing tools

Manual tests

Automated tools find only around 30 percent of accessibility problems. The following manual tests are indispensable:

The keyboard test: Navigate your entire website with the keyboard only. Can you reach and operate every function? Is the focus indicator always visible? Are there keyboard traps?

The screen reader test: Test with NVDA (Windows, free), VoiceOver (macOS and iOS, built in) or JAWS (Windows, commercial). Is all content read out correctly? Are images described? Are forms operable?

The zoom test: Enlarge the page to 200 percent and 400 percent. Is everything readable? Do elements overlap? Does content disappear?

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

User tests with people with disabilities

The most meaningful test method: invite people with various disabilities to test your website. Organisations such as MAIN (Medienarbeit Integrativ) in Austria arrange testers with disabilities. These tests uncover problems that no automated tool and no developer without a disability can find.

Accessibility and SEO: the perfect synergy

Accessibility and search engine optimisation are natural allies. Many accessibility measures improve the Google ranking at the same time. Why? Because search engine bots "read" websites much as screen readers do, they cannot see images, cannot watch videos and cannot interpret JavaScript (or only to a limited degree).

Where accessibility and SEO overlap

Concrete benefits

A lower bounce rate: Accessible websites are easier to use. Users find what they are looking for faster and stay longer. Google reads that as a positive user signal.

A larger audience: 15 to 20 percent of the population have a disability. An accessible website speaks to this audience and generates more traffic, more conversions and more revenue.

Better technical quality: Valid HTML, a correct heading hierarchy and semantic markup are essential for accessibility and for SEO alike.

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

Frequent mistakes in implementation

From our experience at GoldenWing we see these mistakes again and again, even on websites that are supposed to be "accessible":

The top 10 accessibility mistakes

1. Missing or meaningless alt text: "Bild1.jpg" or "DSC_4023" are not alt texts. Just as unhelpful: alt texts that only repeat the keyword without describing the image.

2. Insufficient contrast: Especially in modern, minimalist design with light grey on a white background. Design and accessibility are not a contradiction, they only call for conscious design.

3. Missing keyboard accessibility: Custom components (dropdown menus, tabs, modals) without keyboard control. Particularly frequent with JavaScript frameworks that replace native HTML elements with divs and spans.

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

5. Media that play automatically: Video and audio that start on their own are not only annoying, they are especially problematic for screen reader users.

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

7. CAPTCHAs without an alternative: Conventional CAPTCHAs are unusable for many people. Use accessible alternatives such as hCaptcha Accessibility or invisible CAPTCHAs.

8. Dynamic content without ARIA live regions: Cart updates, error messages and loading notices are not announced by screen readers when aria-live is missing.

9. Missing skip links: On every page keyboard users have to tab through the entire navigation before they reach the main content. A "skip to main content" link solves the problem.

10. The language not defined: The lang attribute is missing from the HTML, which makes screen readers use the wrong pronunciation.

Cost and effort

A frequent question: what does accessibility cost? The answer depends heavily on whether you are retrofitting an existing website or developing a new website to be accessible from the start.

Developing a new website to be accessible

The extra cost compared with a website that is not accessible: 10 to 20 percent. The effort lies mainly in planning, in semantic development and in testing. When accessibility is considered from the start, the extra effort stays manageable.

Retrofitting an existing website

Cost: 20 to 50 percent of the original development cost. Retrofitting is always more expensive than building new, 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 cost

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

The ROI of accessibility

The investment in accessibility pays off:

• An audience 15 to 20 percent larger (people with disabilities)
• A better SEO ranking (see the synergies above)
• A lower bounce rate (a better user experience)
• Legal certainty (avoiding fines and cease and desist letters)
• A positive brand image (social responsibility)

Checklist: an accessible website

This checklist sums up the most important points:

Perceivable:

• All images have descriptive alt text
• Videos have subtitles, transcripts or both
• Contrast meets WCAG AA (4.5:1 for normal text)
• Colour is never the only distinguishing feature
• Text can be enlarged to 200 percent

Operable:

• All functions can be reached by keyboard
• Focus indicators are visible
• Skip links are present
• There are no keyboard traps
• Time limits can be adjusted

Understandable:

• The page language is defined (lang="de")
• The navigation is consistent
• Forms have visible labels and understandable error messages
• Content is written clearly and understandably

Robust:

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

If you need support in making your website accessible, get in touch with our team. GoldenWing offers accessibility audits, training and the implementation of accessible websites from one source.

Frequently asked questions (FAQ)

Does my website have to be accessible?

Since June 2025 the European Accessibility Act (EAA) has obliged many private sector companies to make their digital offerings accessible. Ecommerce, financial services and telecommunications are particularly affected, and only micro enterprises with fewer than 10 employees AND under 2 million euros of annual revenue are exempt. Public bodies in Austria have been obliged since the WZG came in. Even if you are not legally obliged, accessibility pays off economically and ethically.

What does an accessibility audit cost?

A professional WCAG 2.2 audit costs between 1,500 and 8,000 euros depending on the size of the website. A basic audit for a company website with 10 to 30 pages typically lands at 2,000 to 3,500 euros and covers automated tests, manual review and a detailed catalogue of measures with priorities. At GoldenWing we offer audits from 2,500 euros.

Is an automated testing tool enough for accessibility?

No, automated tools such as axe or WAVE find only around 30 percent of accessibility problems. They do detect missing alt text or contrast errors, but they cannot judge whether an 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 tests and ideally user tests with people with disabilities are indispensable.

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 function has to be checked for accessibility. We recommend regular audits (at least annually), automated monitoring tools for continuous oversight and training for everyone who creates content or develops the website further.

Does accessibility harm the design?

A widespread myth. Accessibility and appealing design do not exclude each other, quite the opposite. Many of the most successful websites (Apple, BBC, GOV.UK) are showcases for design that is accessible AND beautiful. The key lies in conscious design: sufficient contrast, clear typography and well thought out interaction patterns improve the design for all users, not only for people with disabilities.

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

That depends on the starting point and the complexity. For a typical company website with 20 to 50 pages, plan 4 to 8 weeks for an audit plus the implementation of the critical measures. Full WCAG AA conformance can take 2 to 4 months on complex websites with many interactive elements. We recommend a phased approach: remove the most critical barriers first (level A), then extend to level AA step by step.

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 technology. But ARIA is frequently used wrongly, which tends to make accessibility worse rather than better.

The golden rule: no ARIA is better than wrong ARIA

Before you use ARIA attributes, always check whether a native HTML element serves the same function. A '<button>' is always better than a '<div role="button">'. Native elements bring keyboard accessibility, focus management and screen reader support with them automatically.

The most important ARIA roles for modern websites

Landmark roles structure your page for screen reader users:

• 'role="banner"', the equivalent of '<header>', the top area of the page
• 'role="navigation"', the equivalent of '<nav>', navigation areas
• 'role="main"', the equivalent of '<main>', the main content
• 'role="contentinfo"', the equivalent of '<footer>', the bottom area
• 'role="complementary"', the equivalent of '<aside>', supplementary content

Note: When you use semantic HTML5 elements, these roles are redundant. Only add them when technical reasons prevent you from using semantic elements.

ARIA states and properties in practice

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

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

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

• 'aria-live="polite"', the change is announced when the user is idle (the default for most cases)
• 'aria-live="assertive"', the change is announced immediately (only for critical messages such as errors)

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

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

Frequent ARIA mistakes and how to fix them

• Redundant roles: '<nav role="navigation">' says the same thing twice. Simply use '<nav>'
• Missing keyboard accessibility: 'role="button"' on a '<div>' does not automatically make it operable by keyboard. You have to add 'tabindex="0"' and keyboard event handlers
• aria-hidden="true" on visible content: Hides content from screen readers although it is visible
• Missing live regions: Dynamic error messages in forms without 'aria-live' are not picked up by screen readers

A testing workflow for ARIA implementations

1. Automated testing: axe DevTools or Lighthouse identify basic ARIA errors
2. A screen reader test: Test with NVDA (Windows, free) or VoiceOver (macOS, preinstalled)
3. Keyboard navigation: Check every interactive area with the keyboard only
4. Browser DevTools: The accessibility panels in Chrome and Firefox show the computed ARIA tree

Accessible forms and interactive elements

Forms are one of the most critical areas for accessibility. In Austria around 18 percent of the population use assistive technology, and those are potential customers you lose through inaccessible forms.

Basic rules for accessible forms

Link labels and input fields correctly:

Every input field needs a clearly assigned label. The link is made through the 'for' attribute on the label and the matching 'id' on the input field. Placeholder text is not a substitute for a label, it disappears as soon as the user types and offers no reliable labelling.

Make error messages accessible:

• Error messages have to be linked programmatically to the field that failed (through 'aria-describedby')
• Use 'aria-invalid="true"' on fields that failed
• Place error messages before or beside the field, not only at the top of the form
• Set the focus on the first error message after submitting

Structure field groups logically:

• Use '<fieldset>' and '<legend>' for fields that belong together (address data or payment information, for example)
• Radio buttons and checkboxes always belong in a field group

Accessible custom components

Dropdown menus and alternatives to select:

• Use the native '<select>' element wherever possible
• With custom dropdowns: implement the full WAI-ARIA combobox specification
• Keyboard control: arrow keys to navigate, enter to select, escape to close

Date pickers:

• The native '<input type="date">' is the most accessible option
• Custom date pickers have to be fully operable by keyboard
• Always offer manual text entry as an alternative

Sliders and range inputs:

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

Making multi step forms accessible

For longer forms (checkout processes, for example) additional requirements apply:

• A progress indicator: Use 'aria-current="step"' for the current step
• Step navigation: Make it possible to return to earlier steps by keyboard
• Preserve input: Fields already filled in have to be preserved when navigating back
• A summary: Offer an accessible summary of all entries before the final submit

Accessibility for ecommerce: making online shops accessible

From 28 June 2025 the Accessibility Strengthening Act (BaFG) applies in Austria, implementing the EU European Accessibility Act (EAA). Online shops are directly affected by it.

The legal requirements for Austrian online shops

The BaFG applies to all companies except micro enterprises (fewer than 10 employees and less than EUR 2 million of annual revenue). The online shops affected have to:

• You have to meet WCAG 2.1 conformance level AA in full
• You have to publish an accessibility statement on the website
• You have to provide a feedback mechanism for accessibility problems
• Breaches risk administrative fines of up to EUR 80,000

The critical areas in ecommerce

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 colour selectors have to be operable by keyboard
• Price information must not be communicated visually only (by a struck through price, for example)

The cart and checkout:

• Quantity changes and delete functions have to be operable by keyboard and screen reader
• Implement status messages ("the item was added") as 'aria-live' regions
• Payment forms have to be fully accessible, including the credit card input fields

Filter navigation:

• Faceted filters have to be operable by keyboard
• Filter changes have to be announced dynamically ('aria-live')
• The number of results has to be communicated after filtering

Search:

• Autocomplete suggestions have to be navigable by keyboard
• Search results have to be announced as a live region
• "No results" messages have to be picked up by screen readers

An accessibility audit for existing shops

Run a structured audit in four phases:

1. Automated scanning: Tools such as axe, WAVE or Lighthouse identify around 30 to 40 percent of all accessibility problems
2. Manual testing: Keyboard navigation through all critical user flows (search, product selection, cart, checkout)
3. Assistive technology testing: Screen reader tests with NVDA or VoiceOver and with magnification software
4. User testing: Tests with people affected, at least 3 to 5 people with different disabilities

The ROI of accessible online shops

Accessibility is not only a legal duty, it makes economic sense too:

• 15 to 20 percent of the population have some form of disability, a considerable group of customers
• Accessible shops achieve on average conversion rates 12 percent higher (better usability for everyone)
• SEO benefits: Accessible websites tend to rank better (clean markup, alt text, semantic HTML)
• Reduced legal risk: Avoiding cease and desist letters and administrative fines

Writing and maintaining an accessibility statement

An accessibility statement has been mandatory for most Austrian websites and online shops since June 2025. It documents the current state of accessibility and shows your users that you take the topic seriously.

The legal basis and the requirements

The Accessibility Strengthening Act (BaFG) and the Web Accessibility Act (WZG) in Austria oblige companies to publish an accessibility statement. It has to be:

• Findable on every website (ideally linked in the footer)
• Written in plain language that everyone understands
• Updated regularly (at least annually)
• Containing contact information for feedback

The mandatory content of an accessibility statement

1. The scope:

Describe which website or websites, or which app or apps, the statement covers. Give the exact URLs.

2. The conformance status:

Choose one of the following formulations:

• "Fully conformant", all WCAG 2.1 AA criteria are met
• "Partially conformant", most but not all criteria are met
• "Not conformant", essential criteria are not met

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

3. Known limitations:

List concretely which areas are not fully accessible:

• "Videos currently have no subtitles (a fix is planned by Q3 2026)"
• "The date picker in the booking function is not fully operable by keyboard"
• "PDF documents from before 2024 have not been prepared for accessibility"

4. The feedback mechanism:

Provide a clear channel of communication:

• A dedicated email address (accessibility@company.at, for example)
• A contact form (which itself has to be accessible)
• A phone number as an alternative

5. The enforcement procedure:

Point to the responsible body in Austria: the Austrian Research Promotion Agency (FFG) as the complaints body for digital accessibility.

A template for an accessibility statement

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

Maintenance and updates

• After every website relaunch: Revise the statement completely
• Quarterly: Update the known limitations
• After accessibility audits: Document the results and the measures
• On user feedback: Record the reported problems and state when they will be fixed

Best practices from the DACH region

You will find exemplary accessibility statements at:

• oesterreich.gv.at: Very detailed, with concrete measures and timelines
• Deutsche Bahn (bahn.de): Transparent communication of known limitations
• Wiener Linien (wienerlinien.at): A clear structure with ways to get in touch

Take your bearings from these examples and match 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 appreciate too.

Accessibility in a redesign: retrofitting existing websites

Many Austrian companies face the challenge of making an existing website accessible without rebuilding the entire project from scratch. With the Accessibility Strengthening Act (BaFG), which takes effect from June 2025, retrofitting is no longer an option for numerous businesses but a legal duty. The good news: a systematic approach makes retrofitting plannable and economically feasible.

Taking stock: where does your website stand today?

Before you start retrofitting you need an honest analysis of the current state. Use a combination of automated and manual tests:

• Automated scans with tools such as axe DevTools, WAVE or Lighthouse uncover around 30 to 40 percent of all barriers, above all missing alt text, poor colour contrast and faulty ARIA attributes
• Manual keyboard navigation: navigate your entire website with the keyboard only. Can you reach every interactive element? Is the focus always visible?
• Screen reader tests: have your pages read out with VoiceOver (macOS and iOS) or NVDA (Windows). Does the order in which things are read make sense? Are images and forms described correctly?
• A content audit: check your texts for clarity, heading structure and the correct markup of language

Document every barrier you find in a structured list with its severity (critical, serious, moderate, minor), the page type affected and the WCAG success criterion. This list becomes your road map for the retrofit.

Setting priorities: the right order of measures

Not all barriers are equally urgent. Prioritise by the impact and effort principle:

Do it immediately (quick wins with a high impact):

• Add the missing alt text for images, this often concerns hundreds of images and is still relatively quick to do
• Adjust the colour contrast, small changes in the CSS file are often enough
• Add the missing form labels, technically simple but enormously important for screen reader users
• Build in skip navigation links, a single component that helps all keyboard users

Do it in the medium term (moderate complexity):

• Correct the heading hierarchy, this calls for changes in the templates and in existing content
• Set ARIA landmarks and roles correctly, it needs technical understanding and improves the page structure massively
• Rework the focus management for dynamic content (modals, accordions, tabs), JavaScript changes are required
• Make sure the responsive behaviour holds for zoom up to 200 percent

Plan it long term (a high effort):

• A complete rebuild of interactive components such as custom dropdowns, date pickers or carousels
• Adding subtitles and transcripts to video and audio content
• Preparing PDF documents for accessibility or replacing them with HTML alternatives
• Making complex data visualisations accessible

The technical retrofit: step by step

For the technical work a component based approach has proven itself. Instead of going through page by page, identify the components your website reuses and make each one accessible:

The header and the navigation: the navigation is the most used element on your website. Make sure the menu is operable by keyboard, that submenus can be closed with escape and that the current section is marked with `aria-current="page"`. With mobile hamburger menus the focus has to jump into the menu when it opens and return to the trigger when it closes.

Forms and contact pages: every input field needs a programmatically linked label. Error messages have to be recognisable both visually and to screen readers, use `aria-describedby` for the error text and `aria-invalid="true"` for fields that failed. Mark required fields not only with an asterisk but also with `aria-required="true"`.

Content areas: make sure all headings form a logical hierarchy (H1 → H2 → H3, with no jumps). Lists use the correct HTML elements (`ul`, `ol`, `dl`). Links are labelled meaningfully, "learn more" without context is useless for screen reader users.

CMS changes for editorial accessibility

The technical retrofit is only half the job. For future content to stay accessible too, you have to adapt your content management system:

• Configure alt text as a required field, no image upload without alternative text
• Predefine heading templates that enforce a correct hierarchy
• Write an editorial guide with clear rules for link labelling, table structure and document formats
• Integrate automatic checks in the CMS that report contrast violations or missing labels before publication

Planning cost and time realistically

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

• The audit and taking stock: 2 to 4 working days
• Implementing the quick wins: 3 to 5 working days
• The component based retrofit: 10 to 20 working days, depending on complexity
• Reworking the content: 5 to 10 working days (heavily dependent on the volume)
• Testing and the final polish: 3 to 5 working days

All in all the cost of a professional retrofit sits between 5,000 and 25,000 euros, considerably cheaper than a complete redesign, which can quickly cost three to five times as much. What matters is that you do not treat the retrofit as a one off measure but integrate it into your quality assurance as an ongoing process.

Conclusion: accessibility is not an obstacle but an opportunity

Website accessibility to WCAG 2.2 is no longer optional in 2026, it is mandatory, legally, economically and ethically. Companies that invest now benefit from a larger audience, better SEO, lower bounce rates and a positive brand image. The cost is manageable, the return on investment measurable.

GoldenWing has been supporting Austrian companies on the way to an accessible website for more than 3 years. From the first analysis through the concept to the technical implementation and ongoing maintenance, we offer everything from one source. Get in touch for a no obligation first conversation and find out how accessible your website is today.

Accessible web design from experts: web design Vienna, accessible and WCAG conformant. The 10 best web design agencies in Vienna give an overview of the market.