Website Accessibility (WCAG): Complete Guide 2026

Website Accessibility (WCAG): The Complete Guide 2026

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

At GoldenWing, we have been implementing accessible websites for over 3 years and are familiar with the challenges, legal requirements, and practical solutions. In this comprehensive guide, you will learn everything you need to know about website accessibility in 2026.

What Is Website Accessibility?

Website accessibility (Web Accessibility) means that a website is designed and developed so that it can be used by all people -- regardless of physical, sensory, or cognitive abilities. This includes people with:

• Visual impairments: Blindness, low vision, color blindness
• Hearing impairments: Deafness, hard of hearing
• Motor impairments: Limited fine motor skills, paralysis, tremor
• Cognitive impairments: Learning disabilities, ADHD, autism, dementia
• Temporary impairments: Broken arm, eye inflammation, loud environment
• Situational impairments: Sunlight on the screen, one-handed operation on the bus

The Curb-Cut Effect

In urban planning, there is the "curb-cut effect": Curb ramps were introduced for wheelchair users but are equally used by parents with strollers, delivery workers with hand trucks, and cyclists. Exactly the same happens on the web: Accessible websites are better usable for EVERYONE.

Clear heading structures help not only screen reader users but also hurried readers. Good contrast makes reading easier in sunlight. Keyboard navigation is also faster for power users than the mouse. Accessibility is not a special case -- it is good web design.

Legal Requirements: EU, Austria, and DACH

The legal requirements for accessible websites have tightened massively in recent years. Companies that do not act now risk legal notices and significant penalties.

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 obligates companies that offer digital products and services to ensure accessibility. Affected areas include:

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

Important: The EAA does not only affect large corporations. SMEs with 10 or more employees or 2 million euros in annual revenue also fall under the regulation. Micro-enterprises are exempt but should still take accessibility seriously.

Austrian Law: Web Accessibility Act (WZG)

In Austria, the Web Accessibility Act (Web-Zugaenglichkeits-Gesetz, WZG) additionally applies, implementing EU Directive 2016/2102. It obligates all public bodies to have accessible websites and apps per WCAG 2.1 Level AA. This includes:

• Federal, state, and municipal authorities
• Public enterprises (e.g., OeBB, Wiener Linien)
• Institutions funded by public bodies
• All websites and mobile applications of these entities

Sanctions: Complaints can be filed with the competent conciliation body. Violations may result in administrative penalties.

Germany: Accessibility Strengthening Act (BFSG)

The German BFSG implements the EAA and has been in effect since June 28, 2025. It extends the obligation for accessibility to the private sector for the first time. Particularly relevant for Austrian companies that also sell in Germany: Online stores and digital services must meet WCAG 2.1 Level AA.

Consequences of Non-Compliance

• Legal notices: Consumer protection associations and affected individuals can sue
• Fines: Up to 100,000 euros in Germany, similar amounts in Austria
• Reputation damage: Public criticism from disability organizations and media
• Competitive disadvantage: Public contracting authorities increasingly require accessibility certifications
• Revenue loss: 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 9 new success criteria.

The Three Conformance Levels

Level A (Minimum): Basic accessibility. If these criteria are not met, certain user groups are completely locked out. Examples: Alternative text for images, keyboard accessibility, no information conveyed solely through color.

Level AA (Recommended and legally required): The standard that laws like the WZG and the EAA require. 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 conformance for entire websites is hardly achievable, but individual criteria should be implemented where possible. Examples: Contrast ratio 7:1, 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 24x24 CSS pixels.
• 3.2.6 Consistent Help: Help mechanisms must be consistently placed.
• 3.3.7 Redundant Entry: Previously entered information 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 assigned to one of these principles.

1. Perceivable

Information and user interface components must be presented in ways that all users can perceive. A blind user cannot see images -- so they need alternative text. A deaf user cannot hear audio -- so they need captions.

Core requirements:

• Alternative text for all non-text content (images, icons, graphics)
• Captions and transcripts for audio and video content
• Content presentable in different ways (e.g., without loss of information when enlarged)
• Sufficient contrast between text and background
• Do not use text as images (except for logos)

2. Operable

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

Core requirements:

• Full keyboard accessibility (Tab, Enter, Escape, arrow keys)
• No keyboard traps (users must not get "trapped" in an element)
• Sufficient time for interactions (timers pausable or extendable)
• No content that triggers seizures (no flash effects above 3 Hz)
• Clear, consistent navigation and orientation
• Visible focus indicator during keyboard navigation

3. Understandable

Information and the operation of the user interface must be understandable. Language must be clear, navigation predictable, and errors must be prevented or explained clearly.

Core requirements:

• Page language defined in HTML (lang="en")
• Foreign language passages marked
• Navigation consistent across all pages
• Form fields labeled and error messages understandable
• Help and error prevention for inputs

4. Robust

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

Core requirements:

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

Practical Implementation: Step by Step

Theory is important, 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 in development.

Contrast and Colors

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

Tools for contrast checking:

• WebAIM Contrast Checker (online)
• Colour Contrast Analyser (desktop app)
• Chrome DevTools (Accessibility Inspector)

Practical tips:

• Never use color as the sole distinguishing feature (e.g., mark red error messages additionally with an icon or text)
• Placeholder text in forms often has insufficient contrast -- use visible labels instead
• Offer dark mode but also pay attention to contrast there
• Distinguish links within body text not only by color but also by underlining

Alternative Text for Images

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

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

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

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

Complex images (charts, infographics): Short alt text plus detailed description in 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 away the mouse and navigating only with the keyboard:

Basic keyboard controls:

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

Focus management:

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

Common problems:

• Custom dropdowns without keyboard controls
• Sliders/carousels not operable with arrow keys
• Hamburger menus that cannot be opened via keyboard
• Focus jumps to top of page after modal closes
• 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 caution: Incorrectly used ARIA does more harm than good.

The first rule of ARIA: Do not use ARIA if 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: Label for elements without visible text (e.g., icon buttons)
• aria-labelledby: Links an element with another element as its label
• aria-describedby: Additional description (e.g., form help text)
• aria-hidden="true": Hides decorative elements from screen readers
• aria-expanded: Indicates whether a collapsible element is open or closed
• aria-live: Defines live regions that are announced when changes occur
• 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>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, 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 with fieldset and legend (e.g., address fields, radio buttons).

Validation: Client-side validation with 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 browsers and password managers can auto-fill fields.

Responsive Design and Accessibility

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

• Text must be enlargeable to 200% without horizontal scrolling
• Touch targets must be at least 44x44 px (WCAG recommends 48x48 px)
• Spacing between touch targets matters (min. 8 px)
• Content must not be clipped or overlaid when zoomed or enlarged
• Support media queries for 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. Also use our Website Design Analyzer as an initial check.

Automated Testing Tools

Manual Tests

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

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

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

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

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

User Testing with People with Disabilities

The most meaningful testing method: Invite people with various disabilities to test your website. Organizations like MAIN (Medienarbeit Integrativ) in Austria connect 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 optimization are natural allies. Many accessibility measures simultaneously improve Google rankings. Why? Because search engine bots "read" websites similarly to screen readers -- they cannot see images, watch videos, or interpret JavaScript (or only to a limited extent).

Overlaps Between Accessibility and SEO

Concrete Benefits

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

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

Better 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 provide clear, structured content that voice assistants can interpret.

Common Implementation Mistakes

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

Top 10 Accessibility Errors

1. Missing or meaningless alt text: "image1.jpg" or "DSC_4023" are not alt texts. Equally unhelpful: Alt texts that only repeat the keyword without describing the image.

2. Insufficient contrast: Especially with modern, minimalist design using light gray tones on white backgrounds. Design and accessibility are not contradictions -- they just require conscious design.

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

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

5. Auto-playing media: Videos and audio that start automatically are not only annoying but especially problematic for screen reader users.

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

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

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

9. Missing skip links: Keyboard users must 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 in the HTML is missing, causing screen readers to use incorrect pronunciation.

Costs 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 with accessibility from the start.

Developing a New Accessible Website

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

Retrofitting an Existing Website

Cost: 20-50% of the original development costs. Retrofitting is always more expensive than new development because existing code must be rewritten, designs adjusted, and content revised. An accessibility audit identifies the most critical barriers as a starting point.

Ongoing Costs

• Regular audits: 1-2x per year, 1,500-5,000 euros
• Content creation: Alt texts, captions, accessible PDFs -- ongoing effort
• Training: Training employees in editorial, design, and development
• Monitoring tools: 100-500 euros/month for automated monitoring

ROI of Accessibility

The investment in accessibility pays off:

• 15-20% larger target audience (people with disabilities)
• Better SEO ranking (see synergies above)
• Lower bounce rate (better user experience)
• Legal certainty (avoiding fines and legal notices)
• Positive brand image (social responsibility)

Checklist: Accessible Website

This checklist summarizes the most important points:

Perceivable:

• All images have descriptive alt texts
• Videos have captions and/or transcripts
• Contrasts meet WCAG AA (4.5:1 for normal text)
• Color is never the sole distinguishing feature
• Text is enlargeable to 200%

Operable:

• All functions are reachable via keyboard
• Focus indicators are visible
• Skip links are present
• No keyboard traps
• Time limits are adjustable

Understandable:

• Page language is defined (lang="en")
• Navigation is consistent
• Forms have visible labels and understandable error messages
• Content is written clearly and comprehensibly

Robust:

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

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

Frequently Asked Questions (FAQ)

Does my website have to be accessible?

Since June 2025, the European Accessibility Act (EAA) obligates many private-sector companies to make their digital offerings accessible. Particularly affected are e-commerce, financial services, and telecommunications -- only micro-enterprises with fewer than 10 employees AND less than 2 million euros in annual revenue are exempt. Public bodies in Austria have already been obligated under the WZG. Even if you are not legally required, accessibility is worthwhile economically and ethically.

How much does an accessibility audit cost?

A professional WCAG 2.2 audit costs between 1,500 and 8,000 euros depending on the scope of the website. A basic audit for a corporate website with 10-30 pages typically costs 2,000-3,500 euros and includes automated tests, manual review, and a detailed action plan with prioritization. At GoldenWing, we offer audits starting at 2,500 euros.

Is an automated testing tool sufficient for accessibility?

No, automated tools like axe or WAVE find only about 30% of accessibility issues. They can detect missing alt texts or contrast errors but cannot assess 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-time 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 oversight, and training for all employees who create content or further develop the website.

Does accessibility hurt 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 aesthetic 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?

That depends on the starting condition and complexity. For a typical corporate website with 20-50 pages, plan 4-8 weeks for an audit plus implementation of critical measures. Full WCAG AA conformance 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: 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 used incorrectly -- which worsens accessibility rather than improving it.

The Golden Rule: No ARIA Is Better Than Wrong ARIA

Before using ARIA attributes, always check whether a native HTML element fulfills the same function. A '<button>' is always better than a '<div role="button">'. Native elements come with keyboard accessibility, focus management, and screen reader support built in.

The Most Important ARIA Roles for Modern Websites

Landmark roles structure your page for screen reader users:

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

Note: If you use 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 collapsible menus, accordions, and dropdowns:

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

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

• 'aria-live="polite"' -- change is announced when the user is inactive (standard for most cases)
• 'aria-live="assertive"' -- change is announced immediately (only for critical messages like 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>'
• Missing keyboard accessibility: 'role="button"' on a '<div>' does not automatically make it keyboard operable. You must add 'tabindex="0"' and keyboard event handlers
• 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 detected 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: Check every interactive area using only the keyboard
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, approximately 18% of the population uses assistive technologies -- these are potential customers you lose through inaccessible forms.

Basic Rules for Accessible Forms

Correctly linking labels and input fields:

Every input field requires a clearly associated label. The association is made via the 'for' attribute on the label and the corresponding 'id' on the input field. Placeholder text is not a substitute for a label -- it disappears upon input and does not provide reliable labeling.

Making error messages accessible:

• Error messages must be programmatically linked to the erroneous field (via 'aria-describedby')
• Use 'aria-invalid="true"' for erroneous fields
• Place error messages before or next to the field, not only at the beginning of the form
• Set focus to the first error message after submission

Structuring field groups logically:

• Use '<fieldset>' and '<legend>' for related fields (e.g., address data, 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 complete WAI-ARIA combobox specification
• Keyboard controls: Arrow keys to navigate, Enter to select, Escape to close

Date pickers:

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

Sliders / 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 navigation: Enable returning to previous steps via keyboard
• Preserve inputs: Already completed fields must be preserved when navigating back
• Summary: Provide an accessible summary of all inputs before final submission

Accessibility for E-Commerce: Making Online Stores Accessible

As of June 28, 2025, the Accessibility Strengthening Act (BaFG) takes effect in Austria, implementing the EU directive European Accessibility Act (EAA). Online stores are directly affected.

Legal Requirements for Austrian Online Stores

The BaFG applies to all companies except micro-enterprises (fewer than 10 employees and less than EUR 2 million annual revenue). Affected online stores must:

• Comply with WCAG 2.1 Conformance Level AA
• Publish an accessibility statement
• Provide a feedback mechanism for accessibility issues
• Violations may result in administrative penalties of up to EUR 80,000

Critical Areas in E-Commerce

Product pages:

• All product images require meaningful alt texts (not just "product image" but "Blue men's polo shirt, size M, organic cotton")
• Size and color selectors must be keyboard operable
• Price information must not be communicated solely visually (e.g., strikethrough price)

Shopping cart and checkout:

• Quantity changes and delete functions must be operable via keyboard and screen reader
• Status messages ("Item has been added") must be implemented as 'aria-live' regions
• Payment forms must be fully accessible -- including credit card input fields

Filter navigation:

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

Search:

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

Accessibility Audit for Existing Stores

Conduct a structured audit in four phases:

1. Automated scanning: Tools like axe, WAVE, or Lighthouse identify approximately 30-40% of all accessibility issues
2. Manual testing: Keyboard navigation through all critical user flows (search, product selection, 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 Stores

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

• 15-20% of the population has some form of disability -- a significant customer group
• Accessible stores achieve on average 12% higher conversion rates (better usability for everyone)
• SEO benefits: Accessible websites tend to rank better (clean markup, alt texts, semantic HTML)
• Reduced legal risk: Avoiding legal notices and administrative penalties

Creating and Maintaining an Accessibility Statement

An accessibility statement is mandatory from June 2025 for most Austrian websites and online stores. It documents the current state of accessibility and shows your users that you take the topic seriously.

Legal Basis and Requirements

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

• Be findable on every website (ideally linked in the footer)
• Be written in plain language
• Be regularly updated (at least annually)
• Contain contact information for feedback

Required Content of an Accessibility Statement

1. Scope:

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

2. 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
• "Non-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:

Specifically list which areas are not fully accessible:

• "Videos currently do not contain captions (correction planned by Q3 2026)"
• "The date picker in the booking function is not fully keyboard operable"
• "PDF documents from before 2024 have not been made 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 body in Austria: the Austrian Research Promotion Agency (FFG) as the complaints body for digital accessibility.

Template for an Accessibility Statement

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

Maintenance and Updates

• After every website relaunch: Completely revise the statement
• Quarterly: Update known limitations
• After accessibility audits: Document results and measures
• Upon user feedback: Record reported problems and specify remediation timelines

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
• Wiener Linien (wienerlinien.at): Clear structure with contact options

Use these examples as models and adapt the level of detail to the size and complexity of your website. A well-maintained accessibility statement signals professionalism and responsibility -- values that your sighted and hearing customers also appreciate.

Accessibility in Redesigns: 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) taking effect in June 2025, retrofitting is no longer optional for many businesses but a legal obligation. The good news: A systematic approach makes retrofitting plannable and economically feasible.

Taking Stock: Where Does Your Website Currently Stand?

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

• Automated scans with tools like axe DevTools, WAVE, or Lighthouse uncover approximately 30-40 percent of all barriers -- primarily missing alt texts, insufficient color contrasts, and faulty ARIA attributes
• Manual keyboard navigation: Navigate your entire website exclusively with the keyboard. Can you reach every interactive element? Is the focus always visible?
• Screen reader tests: Have your pages read by VoiceOver (macOS/iOS) or NVDA (Windows). Does the reading order make sense? Are images and forms correctly described?
• Content audit: Check texts for comprehensibility, heading structure, and correct language markup

Document every barrier found in a structured list with severity (critical, serious, moderate, minor), affected page type, and WCAG success criterion. This list will become your roadmap for retrofitting.

Prioritization: The Right Order of Measures

Not all barriers have the same urgency. Prioritize according to the impact-effort principle:

Implement immediately (quick wins with high impact):

• Add missing alt texts for images -- this often affects hundreds of images but is still relatively quick to implement
• Adjust color contrasts -- small CSS adjustments are often sufficient
• Add missing form labels -- technically simple but enormously important for screen reader users
• Add skip navigation links -- a single component that helps all keyboard users

Implement medium-term (moderate complexity):

• Correct heading hierarchy -- requires adjustments to templates and existing content
• Properly set ARIA landmarks and roles -- requires technical understanding, massively improves page structure
• Rework focus management for dynamic content (modals, accordions, tabs) -- JavaScript adjustments required
• Ensure responsive behavior for zoom up to 200 percent

Plan long-term (high effort):

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

Technical Retrofitting: Step by Step

For technical implementation, a component-based approach has proven effective. Instead of going page by page, identify the reused components of your website and make them individually accessible:

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

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

Content areas: Ensure all headings form a logical hierarchy (H1 -> H2 -> H3, without gaps). Lists use the correct HTML elements (`ul`, `ol`, `dl`). Links are descriptively labeled -- "Learn more" without context is useless for screen reader users.

CMS Adjustments for Editorial Accessibility

Technical retrofitting is only half the battle. To ensure future content also remains accessible, you must adjust 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
• Create an editorial guide with clear specifications for link labels, table structure, and document formats
• Integrate automated checks in the CMS that report contrast violations or missing labels before publication

Realistically Planning Costs and Timeline

For a typical Austrian corporate website with 30-80 pages, plan for the following effort:

• Audit and inventory: 2-4 working days
• Implementing quick wins: 3-5 working days
• Component-based retrofitting: 10-20 working days, depending on complexity
• Content rework: 5-10 working days (heavily dependent on scope)
• Testing and fine-tuning: 3-5 working days

In total, the costs for professional retrofitting range between 5,000 and 25,000 euros -- significantly cheaper than a complete redesign, which can quickly cost three to five times as much. The key is not to view retrofitting as a one-time measure but to integrate it as an ongoing process in your quality assurance.

Conclusion: Accessibility Is Not an Obstacle but an Opportunity

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

GoldenWing has been supporting Austrian companies on the path to accessible websites for over 3 years. From initial analysis to concept development to technical implementation and ongoing maintenance, we offer everything from a single source. Contact us for a non-binding initial consultation and find out how accessible your website currently is.