Skip to main content

Example Accessibility Audit according to WCAG 2.2 A and AA

Portrait of Dmitry Dugarev wearing glasses in a black shirt and smiling

Dmitry Dugarev

Consultant for digital accessibility & IT compliance

In this article, I systematically reviewed the website portfolio.barrierenlos.com/audit-demo against the WCAG 2.2 A and AA criteria [1]. The review took place on April 6, 2025. This involved using both automated tools (Simulated testing with WAVE Browser Extension, manual code inspection) and manual tests with a screen reader and keyboard navigation.

The report is structured like WCAG 2.2 [1], with an evaluation for each criterion. For every unmet WCAG 2.2 criterion (A and AA), detailed explanations with code examples were created, and corresponding to-dos were derived. At the end of the report, there is an overview of all to-dos compiled during the audit. Meeting these to-dos will ensure an accessible website and EAA compliance [2].

The results and recommendations are presented in detail below.

Is Your Website Perceivable for All Users?​

Perceivability is the first of the four foundational principles of web accessibility [3].

It lays the groundwork for ensuring that all users, regardless of their sensory abilities, have access to your content.

Whether someone has a visual impairment, is hard of hearing, or uses special technology to operate the internet—by adhering to the following guidelines, you ensure that no one is excluded.

Provide Text Alternatives for Everything that is Not Text.​

Not Met: Non-text Content – WCAG 2.2, 1.1.1. (A)​

  • Have you provided a brief text alternative for all simple non-text content that fulfills the same purpose and conveys the same information?
  • Have you provided a detailed text description for complex non-text content such as diagrams or infographics? (No such content present)
  • Have you added a clear and unambiguous text description for all controls and input fields that explains their function? (Will be covered under 3.3.2 and 4.1.2, where it fails)
  • Have you provided a suitable brief text description for time-based media or content? (No relevant time-based media present)
  • Have you provided a text description for CAPTCHAs and offered an alternative method? (No CAPTCHA present)
  • Have you implemented or marked non-text content so that it is ignored by assistive technology if it does not provide relevant information?

Numerous images on the website are missing alternative texts. This affects images in almost all sections: slider, features, alternating sections.

Example from the slider:

image.png

Important information is lost for screen reader users, or the context is unclear. Every image that conveys relevant information (is not purely decorative) requires a descriptive alt text [4], [5]. Purely decorative images should have an empty alt="" attribute so that they are skipped by screen readers [6], [7].

Example of an image without alt text
<img src="bild-2.jpg" alt="" width="..." height="..." />

However, all images on this demo page are likely purely decorative and do not require a description. They do not contribute to the content and would likely overwhelm the user with extra content.

To-Dos:

  • Clear alternative texts for all images.
  • Check whether individual images are actually purely decorative and explicitly mark them with alt="".

Provide Alternatives for Time-based Media.​

No time-based media (audio or video) is integrated into this website. Therefore, all requirements in this section are met.

Met: Audio-only and Video-only (Prerecorded) – WCAG 2.2, 1.2.1 (A)​

  • Have you provided an equivalent text alternative for all prerecorded audio content?
  • Have you provided an equivalent text alternative or an audio track for all prerecorded video content without sound?

Met: Captions (Prerecorded) – WCAG 2.2, 1.2.2 (A)​

  • Do you offer captions for prerecorded audio content in synchronized media?

Met: Audio Description or Media Alternative (Prerecorded) – WCAG 2.2, 1.2.3 (A)​

  • Have you provided either an audio description or a text alternative for prerecorded video content?

Met: Captions (Live) – WCAG 2.2, 1.2.4 (AA)​

  • Do you offer captions for live audio content in synchronized media?

Met: Audio Description (Prerecorded) – WCAG 2.2, 1.2.5 (AA)​

  • Have you added an audio description for prerecorded videos in synchronized media?

Create Flexible Content Without Information Loss.​

Your website should be designed to adapt to user needs. This concerns not only the presentation on different devices but also operation with various input methods.

Not Met: Information and Relationships – WCAG 2.2, 1.3.1 (A)​

  • Are information and relationships made programmatically determinable using semantic structure?
  • If the technology used does not support semantic structure, do you offer text alternatives or additional explanations? (HTML supports semantics; it is just not used)

The website's semantic HTML structure is fundamentally flawed. It almost exclusively uses generic <div> and <span> elements instead of semantically correct HTML tags that make the structure and meaning of content understandable for assistive technologies (like screen readers) and browsers [8]. This leads to significant barriers.

Page Structure and Landmarks​

Page areas like the header, navigation, main content, individual sections, and the footer are not marked with the intended HTML5 elements (<header>, <nav>, <main>, <section>, <footer>) [9], [10]. These elements define "Landmark Regions" that allow users of assistive technologies to quickly navigate between important areas of the page.

This is optional, but you can explicitly link the section to this title via aria-labelledby [11] by inputting the id of the title element there. This marks the area as a "Landmark" for users, and they could quickly access it, for example, via the screen reader's Rotor menu, or navigate quickly from one to the next.

If this is not possible, just ensure that the sections are marked with <h1...6> [12]. Users can then quickly orient themselves on the page by having all headings displayed in the Rotor menu.

Excerpt from the website without semantic page structure
<body>
  <div class="site-header"></div>
  <div class="hero">...</div>
  <div class="slider-section">...</div>
  <div class="section">...</div>
  <div class="section-alt">...</div>
  <div class="site-footer">...</div>
</body>

It is important to mention that the first section is not marked as such because the title in this section labels the entire page.

To-Dos:

  • Mark page structure with correct HTML5 Landmark elements: <header>, <nav>, <main>, <section>, <footer>.
  • Give the <main> element an ID (id="main-content") as the target for the Skip Link.
  • Use <section> elements to group thematically related content blocks and name them with headings and aria-labelledby.
Headings​

Headings are represented by visually styled <div> elements (.hero-title, .section-title, .feature-title, .layout-title) instead of genuine heading tags (<h1> - <h6>) [12]. This results in the loss of the document's hierarchical structure, which is essential for screen reader users for navigation and understanding page organization [8], [13].

Excerpt from the website without semantic headings
<div class="hero-title">Unlock Your Potential...</div>
<div class="section-title">Why Choose CoursePro?</div>
<div class="feature-item">
  <div class="feature-title">Expert Instructors</div>
  ...
</div>

To-Dos:

  • Replace all visual headings with correct HTML heading tags (<h1> to <h6>).
  • Ensure that the heading hierarchy is logically correct (only one <h1> per page, no skipping levels).
Lists for Groups​

Groups of related elements, such as navigation items, features in the grid, steps in the "How it Works" section, or FAQ entries, are not marked as semantic lists (<ul>, <ol>, <li>). Instead, <div> containers are often used. As a result, assistive technologies do not recognize that this is a group of related items or how many items are in the group [14].

Excerpt from the website without semantic list structure
<div class="main-nav">
  <div>Features</div>
  <div>Pricing</div>
  <div>Testimonials</div>
</div>

To-Dos:

  • Structure navigation menus as unordered lists (<ul>) with list items (<li>) containing links (<a>).
  • Mark feature grids, testimonial lists, FAQ lists, etc., as <ul> with <li> elements (see also point 4).
  • Mark step-by-step instructions ("How it Works") as ordered lists (<ol>) with <li> elements (see also point 4).
Cards and Articles (<article>)​

Content blocks designed like cards (e.g., individual features, "How it Works" steps, testimonials) often represent self-contained units of information. These should not only be grouped in a list (<ul>/<ol> -> <li>) but the content of each individual card should also be marked with the <article> element.

This would give screen reader users the necessary context by, for example, directly informing them that the list contains two elements.

It is evident there that users are immediately informed that it is a list with four elements (cards). When users select a single element, they are told where that element is in the list and how many elements there are in total.

The <article> element represents a complete or self-contained composition in a document that is intrinsically distributable or reusable (e.g., a forum post, a blog entry, a product on a shop page, or a feature description).

cards"
<div class="features-grid">
  <div class="feature-item">
    <div class="feature-title">Expert Instructors</div>
    <div>Learn from the best...</div>
    <img src="..." />
  </div>
</div>

To-Dos:

  • Structure sections with card layouts (Features, "How it Works," possibly Testimonials) as lists (<ul> or <ol>).
  • Enclose each individual card (e.g., .feature-item, .step-item) in an <li> element.
  • Wrap the entire content within each card with an <article> element.
  • Ensure that each <article> contains a suitable heading (e.g., <h3>, <h4>).
Interactive Elements (FAQ)​

Interactive elements that trigger actions, such as expanding FAQ answers, are implemented as non-interactive <div> elements. These are not keyboard-focusable or activatable by default and lack a suitable semantic role (like "Button") or state information (like "expanded"/"collapsed") [15].

Excerpt from the website without semantic structure for FAQ
<div class="faq-item">
  <div class="faq-question">What payment methods...?</div>
  <div class="faq-answer" style="display: none;">
    ...
  </div>
</div>

To-Dos:

  • Implement FAQ questions as native <button> elements, ideally within a suitable heading (h3, h4...).
  • Structure the entire FAQ section as a list (<ul>/<li>).
  • Add the necessary ARIA attributes (aria-expanded, aria-controls) for the FAQ accordion and manage their state correctly via JavaScript.
  • Give the answer containers a suitable role (role="region") and a link to the question (aria-labelledby with the button's ID) and hide them by default (e.g., with the hidden attribute).
Form Relationships (Labels)​

The input fields (<input>, <textarea>) in the contact form lack associated <label> elements. As a result, the relationship between the visible label (which is only in the placeholder) and the input field is not programmatically determined [16]. Screen readers cannot name the field correctly. (Detailed correction covered in SC 3.3.2 Labels or Instructions).

Excerpt from the website without labels for input fields
<form class="contact-form">
  <input type="text" placeholder="Your Name" />
  <input type="email" placeholder="Your Email Address" />
  <textarea placeholder="Your Message"></textarea>
  <button type="submit">Send Message</button>
</form>

To-Dos:

  • Add explicit <label> elements and correctly link them to the input fields via for/id.
  • Provide <input> elements with the autocomplete attribute to enable automatic form filling.

Met: Meaningful Sequence – WCAG 2.2, 1.3.2 (A)​

  • Is the order of content programmatically determinable and maintained meaningfully? (The DOM order seems to match the visual order)[17]

Met: Sensory Characteristics – WCAG 2.2, 1.3.3 (A)​

  • Do you not rely solely on sensory characteristics (color, shape, size, etc.) for instructions? [18]

Met: Orientation – WCAG 2.2, 1.3.4 (AA)​

  • Can the page be used in both portrait and landscape orientation without loss of functionality or content? (No restrictions found) [19]

Not Met: Identify Input Purpose – WCAG 2.2, 1.3.5 (AA)​

  • Are all fields requesting user data (name, address, email, etc.) programmatically marked as such (e.g., Autocomplete)?

The input fields in the contact form (Name, Email, Message) do not have autocomplete attributes. This makes it difficult for users who rely on browser autofill functions or assistive technologies to fill out the form efficiently [20].

Excerpt from the website without Autocomplete attributes
<input type="email" placeholder="Your Email Address" />

To-Dos:

  • Add appropriate autocomplete attributes for the Name (autocomplete="name") and Email (autocomplete="email") fields in the contact form.

Make Content Clear and Easily Recognizable.​

The readability and recognizability of content are crucial for accessibility. Ensure that texts are easy to read, colors have sufficient contrast, and font sizes are large enough. Operating elements should also be clearly recognizable and distinguishable from each other. It is particularly important that colors do not serve as the sole source of information, as they may not be perceivable to many users.

Met: Use of Color – WCAG 2.2, 1.4.1 (A)​

  • Do you not rely solely on color to convey information (e.g., states)? [21]
  • If color is used in images, have you integrated alternative representations (e.g., patterns, labels)?

Met: Audio Control – WCAG 2.2, 1.4.2 (A)​

  • Do audio contents not play automatically for longer than 3 seconds, or do you offer a stop/pause button? (No audio content present) [22]

Not Met: Contrast (Minimum) – WCAG 2.2, 1.4.3 (AA)​

  • Does larger text (e.g., 18 pt or 14 pt bold) have a contrast of at least 3:1? Does normally sized text (below 18 pt and below 14 pt bold) have a contrast of at least 4.5:1?

Several text elements on the page do not meet the minimum contrast requirements according to WCAG AA [23], [24]:

  • Placeholder text in forms: The placeholder text (#999) on a white background (#ffffff) has a contrast ratio of only 2.85:1. This is too low; 4.5:1 is required.

    image.png

  • Button Text:

    • Green button (#28a745 BG, #fff Text): Contrast 3.98:1 (too low for normal text; 4.5:1 is required). image.png

To-Dos:

  • Darken the color of the placeholder text or ensure that fields always have a visible <label>.
  • Adjust the background or text colors of the buttons (green) so that the contrast is at least 4.5:1 (since the text is normal size).

Met: Text Resizing – WCAG 2.2, 1.4.4 (AA)​

  • Can your text be resized up to 200% without content loss or becoming unusable? (Standard browser zoom works) [25]

Met: Images of Text – WCAG 2.2, 1.4.5 (AA)​

  • Do you avoid images of text if the same effect can be achieved with real text?

Not Met: Reflow – WCAG 2.2, 1.4.10 (AA)​

  • Does all content remain usable without horizontal scrolling and without loss of information up to a width of 320 CSS pixels?

Unfortunately, there is horizontal scrolling:

image.png

This happens because the containers in the sections with an image on the left have margin: 0 auto; and width: 90% simultaneously. One of these properties must be removed on mobile [26], [27].

To-Dos:

  • Remove width: 90% or margin: 0 auto; from the .container class on mobile.

Not Met: Non-text Contrast – WCAG 2.2, 1.4.11 (AA)​

  • Do user interface components (buttons, focus outlines, etc.) have a contrast of at least 3:1 against the background?
  • Do graphics contain important areas that show a contrast of at least 3:1? (No complex graphics whose understanding depends on contrast)

Several user interface components on the page do not meet the non-text contrast requirements according to WCAG AA [28], [29]:

  • Form field borders: The borders of the input fields (#ccc) on a white background (#ffffff) have a contrast ratio of only 1.61:1. This is too low for the component to be recognizable.

    image.png

  • Focus indicators: There are no visible focus indicators for interactive elements ( see 2.4.7). Thus, the necessary contrast for the focus indicator itself is also missing. image.png

To-Dos:

  • Darken the color of the input field borders to achieve a contrast of at least 3:1 (e.g., #767676).
  • Implement visible focus indicators with sufficient contrast (see 2.4.7).

Met: Text Spacing – WCAG 2.2, 1.4.12 (AA)​

  • Does your page remain fully usable when line and paragraph spacing, word spacing, and character spacing are increased? (No techniques found that prevent this) [30]

Met: Content on Hover or Focus – WCAG 2.2, 1.4.13 (AA)​

  • Does additionally displayed content (e.g., tooltips) remain visible until you close it or remove the focus? (No such content present)

Is Your Website Operable for All Users?​

The second cornerstone of accessibility is operability [3].

This aspect ensures that all users—regardless of their physical abilities or the technology they use—can navigate your website without problems and utilize all functions.

Make All Functions Accessible via Keyboard.​

Not Met: Keyboard – WCAG 2.2, 2.1.1 (A)​

  • Is all functionality of your webpage operable via the keyboard, without specific time limits?

Several central functions and interactive elements of the website are not operable via the keyboard [31]. This excludes users who cannot use a mouse or rely on keyboard navigation (e.g., users with motor impairments or screen reader users).

The main navigation elements are implemented as <div> elements. <div> elements are not interactive by default and do not receive keyboard focus. They cannot be reached with the Tab key and cannot be activated with Enter or the Space bar [31].

Only native interactive elements like links (<a> with href) and buttons (<button>, <input type="button">, etc.) or elements with explicit tabindex="0" [32] are keyboard-focusable and operable by default. Using <div>s for navigation prevents this.

Excerpt from the website without semantic structure for navigation
<div class="site-header">
  <div class="container nav-container">
    <div class="logo">CoursePro</div>
    <div class="main-nav">
      <div>Features</div>
      <div>Pricing</div>
      <div>Testimonials</div>
      <div>Contact</div>
      <div>FAQ</div>
    </div>
  </div>
</div>

To-Dos:

  • Replace the <div> elements of the navigation with real <a> elements with meaningful href attributes.
  • Structure the navigation semantically correctly as a list (<ul>/<li>) within a <nav> element [14], [33].
FAQ Not Keyboard Operable​

The questions in the FAQ section, which are used to expand/collapse the answers, are also implemented as <div> elements (<div class="faq-question">). As with the navigation, these are not keyboard-focusable or activatable [31].

For such an expand/collapse function (accordion), a <button> element is the semantically correct and accessible choice [15]. Buttons are keyboard-focusable and can be triggered with Enter/Space bar to start the associated action (here: expanding/collapsing the content via JavaScript).

Excerpt from the website without semantic structure for FAQ
<div class="faq-item">
  <div class="faq-question">What payment methods do you accept?</div>
  <div class="faq-answer" style="display: none;">
    ...
  </div>
</div>

To-Dos:

  • Replace the <div> elements for FAQ questions (.faq-question) with <button> elements.
  • Ensure that these buttons correctly control the state (aria-expanded) and visibility of the answers (hidden attribute) via JavaScript [15].
No Keyboard Control for Slider/Marquee​

The automatically running image slider and the text marquee offer no controls whatsoever. Consequently, there are no keyboard-operable controls to manage this dynamic content (e.g., to stop, pause, or manually browse) [31], [34].

Any functionality triggered via mouse or automatically must also have equivalent keyboard operation. For sliders and marquees, this generally means buttons to pause/start the animation and potentially for manual navigation. These buttons must be implemented as <button> to ensure keyboard operability.

Excerpt from the website without keyboard control for slider and marquee
<div class="slider-section">
<div class="slides-wrapper">...</div>
</div>

<div class="marquee-section">
<div class="marquee-content">...</div>
</div>

To-Dos:

  • Add explicit controls (at least Play/Pause) for the slider and the marquee. Implement these as <button> elements.
  • Ensure that these buttons are reachable via the keyboard and their function (stop/start animation) can be triggered via Enter/Space bar (via JavaScript event listener).
  • For the slider, additionally implement Previous/Next buttons (<button>) to enable manual keyboard navigation.

Met: No Keyboard Trap – WCAG 2.2, 2.1.2 (A)​

  • Is there no keyboard trap? Can you move or leave the focus at any time? (No trap detectable) [37]

Met: Character Key Shortcuts – WCAG 2.2, 2.1.4 (A)​

  • If you use character key shortcuts (letters/numbers), can they be disabled or remapped, or do they only work when the element has focus? (No such shortcuts implemented)

Give Users Enough Time to Read and Use Content.​

Met: Timing Adjustable – WCAG 2.2, 2.2.1 (A)​

  • Can you turn off or extend session time limits (at least 10 times)? (No time limits implemented) [38]
  • Does a script control the time limit? Can you turn it off or extend it? (No time limits implemented)
  • Do you have a pause or stop function for time-limited reading (e.g., running text)? (Marquee is a problem under 2.2.2)

Not Met: Pause, Stop, Hide – WCAG 2.2, 2.2.2 (A)​

  • Can you stop, pause, or hide moving, blinking, or automatically updating content?

Several automatically running contents on the page offer no way to stop or pause the movement [35]. This particularly affects:

  • Slider: The image slider in the upper section of the page runs automatically and continuously, without the user having any way to stop it, pause it, or manually switch slides [34].
  • Marquee: The marquee with text ("Trusted By Thousands...") also runs automatically and endlessly via CSS animation, without controls.

These automatically moving contents can be very distracting or even harmful for users with cognitive disabilities, attention deficit disorders, or vestibular disorders.

To-Dos:

  • Add controls for the slider (e.g., Pause/Play button, Previous/Next arrows, slide indicators) that are also keyboard operable.
  • Also offer a Pause/Play function for the marquee or stop the animation by default and only start it upon user action.
  • Alternatively or additionally: Respect the CSS media query prefers-reduced-motion and disable animations for users who have set this in their system.

Avoid Content that Can Cause Seizures or Physical Reactions.​

Met: Three Flashes or Below Threshold – WCAG 2.2, 2.3.1 (A)​

  • Does your website contain no flashing or flickering content that could trigger seizures? [39]

Make Your Website Navigable for All Users.​

There is not only the mouse and the touchscreen. Many users employ keyboards, screen readers, or other aids to move through your website.

Not Met: Skip Blocks – WCAG 2.2, 2.4.1 (A)​

  • Can you skip repeating content, e.g., with a "Skip to Content" link?

The website lacks a mechanism to skip repeating blocks such as the main navigation. Keyboard users must tab through all navigation elements on every page view before reaching the main content [40].

Screenshot 2025-02-20 at 22.15.22.png

The first hidden navigation area serves as a "Skip Link" to allow users—especially those using assistive technologies—to jump directly to the main content. By using aria-label, the link's purpose is clearly communicated.

Example of a 'Skip to Content' link with jump target area
<nav aria-label="Skip target area">
  <ul class="stmc-links__wrapper">
    <li>
      <a href="#skip-link-target" title="Skip to main content" class="stmc-link"
        >Skip to main content
      </a>
    </li>
  </ul>
</nav>

Alternatively, you can simply place a link as the first element on the page [40]:

Simple 'Skip to Content' link
<a href="#skip-link-target" title="Skip to main content" class="stmc-link">
  Skip to main content
</a>

To-Dos:

  • Ensure that the link is visible and clearly recognizable when navigating with the keyboard.
  • Check whether the jump target area (id="skip-link-target") is correctly defined and immediately follows the main content.

Met: Page Titled – WCAG 2.2, 2.4.2 (A)​

  • Does every page have a meaningful title that conveys the topic or purpose? (The <title> "Inaccessible Course Platform - Demo v2" is present) [41]

Met: Focus Order – WCAG 2.2, 2.4.3 (A)​

  • Is the focus order logical so that meaning and operability are not impaired? (The order seems logical within the focusable elements) [42]

Not Met: Link Purpose (In Context) – WCAG 2.2, 2.4.4 (A)​

  • Is the purpose of each link unambiguous via the visible link text or the programmatically defined context?

The purpose of elements intended for navigation is often not programmatically determinable or is obscured by the use of semantically incorrect elements. This prevents users of assistive technologies from correctly identifying navigation options and understanding where a click leads [43].

The main navigation and the links in the footer use <div> or <span> elements instead of actual links (<a>). Although the visible text (e.g., "Features," "Privacy Policy") may be understandable to sighted users, these elements lack the semantic role of a link. Assistive technologies do not recognize them as navigation elements, and the purpose ("navigate to another page/section") is not programmatically evident.

image.png

image.png

Excerpt from the website with non-semantic navigation
<div class="main-nav">
  <div>Features</div>
  <div>Pricing</div>
</div>

Only a correctly implemented <a> element with an href attribute clearly signals the role and purpose of a hyperlink [44]. The link text itself should then describe the target or function of the link [43].

Example of semantically correct navigation
<nav aria-label="Main navigation">
  <ul class="main-nav">
    <li>
      <a href="#features">Features</a>
    </li>
    <li>
      <a href="#pricing">Pricing</a>
    </li>
    <li>
      <a href="#testimonials">Testimonials</a>
    </li>
  </ul>
</nav>

To-Dos:

  • Implement all elements intended for navigation (header navigation, footer links) as correct <a> elements with valid href attribute and meaningful link text.
  • Ensure that these links are embedded in a semantically correct structure (e.g., nav > ul > li > a).

In several places, <button> elements are used for Call-to-Actions (CTAs) whose primary function is navigation to another page or section (e.g., "Get Started Today," "Explore Courses").

image.png image.png image.png

Semantically, a <button> is intended for actions within the current page (submitting a form, changing state, opening a dialog). For pure navigation, a link (<a>) is the correct element [44]. The use of a button conveys a false expectation about the action to be performed to assistive technologies.

Although the button text may be clear, the role="button" signals an action, not navigation. This can be confusing. If the click leads the user to another URL or an anchor on the page, an <a> element should be used and styled to look like a button.

Excerpt from the website with buttons for navigation
<button class="cta-button">Get Started Today</button>
<button class="section-cta-button">Explore Courses</button>

To-Dos:

  • Review all <button> elements on the website.
  • Replace buttons whose main function is navigation to another URL or an anchor with <a> elements with the corresponding href attribute.
  • Ensure that the link text clearly describes the purpose or destination of the link.
  • Transfer the visual appearance of buttons to the <a> elements via CSS if necessary.

Not Met: Multiple Ways – WCAG 2.2, 2.4.5 (AA)​

  • Do you offer multiple navigation paths (e.g., search, sitemap, menu) to find pages?

The website only offers a primary navigation (in the header, which is also inaccessible) and a rudimentary link collection in the footer (which is also inaccessible). There is no sitemap and no search function. Thus, alternative ways to find content are missing, especially if the main navigation is not usable [45], [46], [47].

To-Dos:

  • Provide at least one more way to navigate. Options:
    • Create and link a sitemap page.
    • Implement a search function.
    • Ensure that the main navigation and footer navigation consistently link all important pages.

Not Met: Headings and Labels – WCAG 2.2, 2.4.6 (AA)​

  • Are headings and labels meaningful and describe the topic or purpose?

Several headings and form labels on the page are not semantically correctly implemented, which makes navigation and comprehension difficult for users of assistive technologies [48], [49]. This particularly affects:

  • Headings: As described under 1.3.1, no genuine heading tags (<h1><h6>) are used. Styled <div>s do not fulfill the purpose of programmatically structuring the page [12].
  • Labels: As described under 3.3.2, the form fields in the contact area lack explicit <label> elements. Placeholders are not adequate labels [16].

To-Dos:

  • Use genuine, hierarchically correct headings (<h1> to <h6>) for all sections and subsections.
  • Provide explicit, correctly linked <label> elements for all form fields.

Not Met: Focus Visible – WCAG 2.2, 2.4.7 (AA)​

  • Is the keyboard focus visible when you navigate through the page?

The page's CSS lacks explicit :focus-visible styles for all interactive elements [50]. This affects:

  • The <div> elements in the navigation (which are not focusable anyway).
  • The <button> elements (Hero CTA, Form Submit, Section CTAs).
  • The <input> and <textarea> fields in the contact form.
  • The <div> elements of the FAQ questions (which are also not focusable).

Without a visible focus indicator, keyboard users do not know which element is currently active, which makes operation extremely difficult or impossible [50].

To-Dos:

  • Define clearly visible :focus styles for all interactive elements (links, buttons, form fields, etc.) in the CSS. The focus indicator must clearly stand out from the background and the element itself (see also 1.4.11 Non-text Contrast). A simple outline is often sufficient, e.g.:
Example of focus styles in CSS
button:focus-visible,
input:focus-visible,
textarea:focus-visible,
a:focus-visible,
[tabindex='0']:focus-visible {
  outline: 2px solid blue; /* Example */
  outline-offset: 2px;
}

Met: Focus Not Obscured (Minimum) – WCAG 2.2, 2.4.11 (AA)​

  • Is the focus indicator not obscured by other content when an element receives focus? (No sticky headers/footers or non-modal dialogs present that would obscure the focus)

Make Your Website Accessible for All Input Methods.​

Met: Pointer Gestures – WCAG 2.2, 2.5.1 (A)​

  • Can all multi-finger or path gestures (e.g., swiping, pinch-to-zoom) also be operated simply with a single pointer? (No such gestures required)

Met: Pointer Cancellation – WCAG 2.2, 2.5.2 (A)​

  • Is an action only completed upon pointer up (MouseUp / TouchEnd) or is there an undo/cancel option? (Standard behavior of buttons/inputs) [51]

Not Met: Label in Name – WCAG 2.2, 2.5.3 (A)​

  • Does the visible text in the label match the accessible name?

Since the fields do not have visible <label> elements, this criterion cannot be met. The accessible name (which would be provided by a label) is missing [16], [52]. Placeholders do not count as a label.

To-Dos:

  • Add visible <label> elements for all form fields (see 3.3.2). Ensure that the text in the label clearly describes the purpose of the field.

Met: Motion Actuation – WCAG 2.2, 2.5.4 (A)​

  • Can device movements (e.g., shaking) also be executed via a user interface component and do you deactivate unintended triggers? (No motion-activated functions) [53]

Met: Dragging Movements – WCAG 2.2, 2.5.7 (AA)​

  • Can the function that requires dragging (Drag & Drop) also be executed without dragging? (No Drag & Drop present)

Met: Target Size (Minimum) – WCAG 2.2, 2.5.8 (AA)​

  • Are all clickable/touchable areas at least 24x24 CSS pixels large or sufficiently separated? (Visually, the buttons and links (if they were links) seem large enough or far enough apart)

Is Your Website Understandable for All Users?​

Your website should be designed so that all users can understand the content and operation [3]. This includes clear language, simple navigation, and understandable interactions. Pay particular attention to ensuring that screen readers pronounce the language correctly and that operation is logical.

Make Your Website Readable for All Users.​

Met: Language of Page – WCAG 2.2, 3.1.1 (A)​

  • Is the page's default language correctly marked (e.g., lang="de")? (lang="en" is set in the HTML, which corresponds to the content's language) [54]

Met: Language of Parts – WCAG 2.2, 3.1.2 (AA)​

  • Do you mark language changes in the text (e.g., quotes, foreign words, customer reviews, etc.) with lang attributes? (No obvious language changes in the demo content) [55]

Make Your Website Predictable for All Users.​

Met: On Focus – WCAG 2.2, 3.2.1 (A)​

  • Does the context not change automatically as soon as an element receives focus? [56]

Met: On Input – WCAG 2.2, 3.2.2 (A)​

  • Does the context not change automatically as soon as a value is changed in a form element? [57]

Met: Consistent Navigation – WCAG 2.2, 3.2.3 (AA)​

  • Are navigation elements that are repeated across multiple pages always arranged in the same order? (Since there is only one page, this is trivially met) [58]

Met: Consistent Identification – WCAG 2.2, 3.2.4 (AA)​

  • Are elements with the same function consistently labeled and identified (e.g., same icons, colors)? (Buttons have consistent styling) [59]

Not Met: Consistent Help – WCAG 2.2, 3.2.6 (A)​

  • Are help functions (contact, FAQ, chat, etc.) offered in the same location on all pages?

While the website offers an FAQ section and a Contact section, there is no consistent, easily discoverable mechanism for help that would be available on every (hypothetical) page (e.g., an always-present "Help" link in the header or footer). The links to the FAQ and Contact in the header are also inaccessible (see 2.1.1, 1.3.1).

To-Dos:

  • Provide a consistent help mechanism on all pages. This could be a link to a help page, contact information, or an FAQ page, consistently placed in the same location (e.g., in the header or footer) and accessible [60], [61].

Help Users Avoid and Correct Mistakes.​

Not Met: Error Identification – WCAG 2.2, 3.3.1 (A)​

  • Are input errors automatically detected and is the erroneous element communicated to the user and the error textually described?

The current contact form code contains no mechanisms for error detection or communication. If a user submits the form with errors (e.g., empty required fields, invalid email format), it is not ensured that:

  1. The error is detected at all (validation is missing).
  2. The erroneous field is programmatically marked as such (e.g., for screen readers) [62].
  3. A clear textual description of the error is provided and linked to the field [63], [64].

This results in users, especially those relying on assistive technologies, potentially not noticing that an error has occurred, which field is affected, or how to fix the error.

Problem Description using a Form Field Example​

A typical input field in the current code offers no structure to display errors or communicate them programmatically.

To meet WCAG 3.3.1, upon validation (client- or server-side), the affected input field must be clearly identified, and the error described. This typically happens through:

  • Visual highlighting (e.g., red border).
  • Setting the aria-invalid="true" attribute on the erroneous <input> element [62]. This signals the error state to assistive technologies.
  • Displaying a textual error message in the immediate vicinity of the field.
  • Linking the <input> element to the error message via the aria-describedby attribute [65]. The attribute value must match the id of the element containing the error message. Screen readers typically read the label first, then the field type, and finally the error text linked via aria-describedby.
Excerpt from the contact form without error detection
<div>
  <input
    type="email"
    id="contact-email"
    name="contact-email"
    placeholder="Your Email Address"
  />
</div>

To-Dos:

  • Implement client-side and/or server-side validation logic for the contact form (e.g., check for empty required fields, correct email format).
  • When an error occurs: Dynamically set (e.g., via JavaScript) the aria-invalid="true" attribute on the erroneous <input> or <textarea> element.
  • Display a clear, textual error message in the immediate vicinity of the erroneous field. Give this error message element a unique id.
  • Add the aria-describedby attribute to the erroneous <input>/<textarea> element, whose value points to the id of the associated error message.
  • Ensure that the error is also visually clearly recognizable (e.g., through color, icon, highlighting of the field and/or the error message).
  • Remove aria-invalid="true" and aria-describedby (or hide the error message) as soon as the error has been corrected.

Not Met: Labels or Instructions – WCAG 2.2, 3.3.2 (A)​

  • Do all controls requiring user input have associated labels or instructions?

The input fields (<input>, <textarea>) in the contact form do not have explicit, programmatically linked <label> elements. Instead, placeholder attributes are used to suggest the purpose of the fields. This is problematic and insufficient for several reasons [16], [67]:

  1. Ephemerality: Placeholder text disappears as soon as the user starts typing, causing the information about the expected content to be lost.
  2. Detection by Assistive Technologies: Placeholders are not reliably recognized by all browser/screen reader combinations as the accessible name for the field [67]. However, the accessible name is crucial so that screen reader users know which field they are currently editing.
  3. Contrast: Placeholder text often has low color contrast to the background, making readability difficult for users with visual impairments.
  4. Purpose: Placeholders are primarily intended for short hints or format examples, not as a replacement for a permanent label.

Without correct labels, the essential programmatic link between the description and the input field is missing [16].

Problem Description and Code​

The current code shows input fields without associated <label> elements.

The standard and most robust method for providing labels for form fields is using the <label> element. By linking the for attribute of the label to the id of the corresponding input element (<input>, <textarea>, <select>), a clear programmatic connection is established [16]. This connection allows assistive technologies to read the label correctly when the field receives focus. Additionally, mouse users benefit because clicking the label sets the focus into the associated input field.

Excerpt from the contact form without labels
<div class="contact-form">
  <div>
    <input type="text" placeholder="Your Name" />
  </div>
  <div>
    <input type="email" placeholder="Your Email Address" />
  </div>
  <div>
    <textarea rows="6" placeholder="Your Message"></textarea>
  </div>
  <div>
    <button class="submit-button" type="button">Send Message</button>
  </div>
</div>

To-Dos:

  • Add a visible <label> element for every <input> and <textarea> element in the contact form.
  • Give each input field a unique id.
  • Set the for attribute of each <label> element to the id of the corresponding input field to establish the programmatic link [16].
  • If additional instructions are necessary (e.g., about required formats or lengths), provide them as visible text near the field (e.g., below the label or input) and link them additionally via aria-describedby if necessary (see also SC 3.3.1 [69] and 3.3.3). Use placeholders only for short, non-essential hints or examples.

Not Met: Error Suggestion – WCAG 2.2, 3.3.3 (AA)​

  • For empty required fields, do you offer a hint (e.g., "This field must not be empty")? (Error detection is generally missing, thus assumption: No)
  • If a specific data format is required, do you suggest a correction?
  • If only certain values are allowed (e.g., a selection list), do you provide a corresponding hint or suggestion? (No such fields present)

Since no error detection is implemented (see 3.3.1 [69]), no correction suggestions are made either [70]. If a user enters an invalid email address, for example, they would (presumably) not receive a specific message that helps them correct the error (e.g., "Please enter a valid email address in the format name@domain.com.").

Met: Error Prevention (Legal, Financial, Data) – WCAG 2.2, 3.3.4 (AA)​

  • For legally or financially relevant actions (e.g., purchase, tax return), do you offer options for modification or reversal? (Not applicable)
  • If user data is deleted or changed, can it be undone or confirmed? (Not applicable)
  • For tests (e.g., exams, questionnaires), do you give the opportunity to review or change answers before they are finally submitted? (Not applicable)

Met: Redundant Entry – WCAG 2.2, 3.3.7 (A)​

  • Do you avoid duplicate entries within a process or do you automatically fill in previously entered data? (Not applicable for the simple contact form)

Met: Accessible Authentication (Minimum) – WCAG 2.2, 3.3.8 (AA)​

  • Do you avoid purely cognitive testing steps (e.g., complicated passwords, riddles), or do you offer alternatives? (No authentication present)

Is Your Website Robust Enough?​

The fourth and final cornerstone of accessibility is robustness [3].

This aspect ensures that your website remains compatible with future technologies and is correctly interpreted by a variety of user agents, including assistive technologies.

By paying attention to clean HTML and adhering to web standards, you increase the longevity and accessibility of your website.

Maximize Compatibility with All Technologies Users Employ.​

Not Met: Parsing – WCAG 2.2, 4.1.1 (A)​

  • Are elements nested according to their specification, do they have start and end tags, and no duplicate attributes/IDs?

Although no explicit validation was performed, the massive semantic errors (use of div for everything) indicate that the HTML structure likely does not comply with the specifications for the correct use of elements. Valid parsing is probably given, but the correct application of HTML is fundamentally violated.

To-Dos:

  • Check code with an HTML validator (e.g., W3C Nu HTML Checker).
  • Use correct semantic elements (see 1.3.1).

Not Met: Name, Role, Value – WCAG 2.2, 4.1.2 (A)​

  • Do you use standardized UI components (e.g., HTML forms) according to the WHATWG HTML specification [74], so that Name/Role are recognizable?
  • If you repurpose standard components or script new ones, do you ensure correct marking of Name/Role?
  • If you use standard components in a programming language, do you ensure that Name/Role can be read out via API? (Not applicable)
  • If you program your own UI components, do you expose Name/Role/State via ARIA or Accessibility APIs? (ARIA is not used)

This criterion is violated in many places [75], [76]:

  • Navigation & Footer Links: <div> and <span> are used instead of <a>. Role ("Link") is missing.
  • Headings: <div> instead of <h1><h6>. Role ("Heading") is missing.
  • FAQ: <div> is used as an interactive trigger instead of <button>. Role ("Button") and state (aria-expanded) are missing. - Form Fields: Missing <label>s result in the accessible name of the fields not being correctly determinable. - Slider/Marquee: No roles (e.g., role="region", aria-live) or states defined that make the function understandable for assistive technologies.
  • Form Fields: Missing <label>s result in the accessible name of the fields not being correctly determinable.
  • Slider/Marquee: No roles (e.g., role="region", aria-live) or states defined that make the function understandable for assistive technologies.

To-Dos:

  • Use native HTML elements for their intended purpose (links, buttons, headings, lists, form elements).
  • Where native elements are insufficient (e.g., for custom widgets like the FAQ accordion), implement correct ARIA roles, properties, and states (role, aria-label, aria-expanded, aria-controls, etc.).
  • Ensure that all form fields receive an accessible name through correctly linked <label> elements.

Not Met: Status Messages – WCAG 2.2, 4.1.3 (AA)​

  • Do you output status messages (e.g., "Success" or "Data saved") so that assistive technologies perceive them without receiving focus? (No status messages implemented)
  • Do error messages or warnings (e.g., validation errors) also appear programmatically perceivable (role="alert" or similar)?
  • Is a progress (e.g., loading bar) announced live via role or live region (e.g., role="progressbar" or role="log")?** (No progress indicators implemented)

As described earlier, error handling is missing. If error messages are added, they must be implemented so that they are automatically perceived by assistive technologies (like screen readers) without the user having to manually move the focus there. This typically happens by using role="alert" or aria-live regions [77].

To-Dos:

  • Place dynamically appearing status and error messages (e.g., after form submission) in a container with role="alert" or role="status" (depending on urgency) so that they are announced to screen readers.

Now, all 55 requirements of WCAG 2.2 have been checked on your website. The website failed to meet 20 out of 55 WCAG 2.2 criteria. Therefore, your website does not yet have a presumption of conformity [78].

All To-Dos Summarized​

Image Alternatives & Media​

Alt Text / Decorative Images​

  • Create meaningful alternative texts for all informative images (Hero, Slider, Features, Alternating Sections, How it Works) and include them in the alt attribute [4], [5].
  • Check whether individual images are actually purely decorative and explicitly mark them with alt="" [6].

Semantic Structure & HTML Errors​

HTML Validation & Structure​

  • Check code with an HTML validator (e.g., W3C Nu HTML Checker) and fix errors [71].
  • Use correct semantic HTML elements for the page structure (<header>, <nav>, <main>, <section>, <footer>, <article>) [10].
  • Mark headings hierarchically correctly with <h1> - <h6> [12], [13].

Lists & Groupings​

  • Structure navigation menus, feature lists, step lists, FAQ lists, etc., as HTML lists (<ul>/<ol> with <li>) [14].

Sections & Landmarks​

  • Check all important content sections and mark them as Landmarks using aria-label or aria-labelledby if native elements like <nav>, <main> are insufficient [10].

ARIA Attributes & Interactive Elements​

Optimize Interactive Elements​

  • Implement interactive elements (navigation links, FAQ triggers, footer links) as native links (<a> with href) or buttons (<button>) [31], [44].
  • Use ARIA attributes (aria-expanded, aria-controls, role="region" for content) for interactive components like the FAQ accordion [15].
  • Place dynamically appearing status and error messages (e.g., after form submission) in a container with role="alert" or role="status" [77].

Navigation & Keyboard Accessibility​

Quick Access & Navigation​

  • Implement a "Skip-to-Content" link as the first focusable element (visually hidden until focused) [40].
  • Ensure that the purpose of each link (via visible link text or ARIA attributes) is unambiguously recognizable (after conversion to <a>) [43].
  • Provide at least one more way to navigate (sitemap, search, or consistent menus) [45], [46], [47].

Focus & Keyboard Operation​

  • Define clearly visible :focus styles for all interactive elements (links, buttons, form fields, etc.) in the CSS [50].
  • Ensure that all interactive elements are reachable and operable via the keyboard (navigation, FAQ, slider/marquee controls) [31].

Contrast, Design & Visual Requirements​

Text & Non-text Contrast​

  • Adjust color contrasts for text (placeholders, buttons, Hero) according to WCAG AA (4.5:1 for normal text, 3:1 for large text) [23], [24].
  • Ensure contrast for user interface components (form field borders, focus indicator) according to WCAG AA (3:1) [28], [29].

Animation & Motion​

  • Add controls for the slider and marquee to stop/pause, which are keyboard operable [34], [35].
  • Respect the CSS media query prefers-reduced-motion and disable animations if necessary.

Forms & Input Fields​

Labeling & Input Purpose​

  • Add a visible <label> element for every input field in the contact form and link it correctly (for/id) [16].
  • Add appropriate autocomplete attributes for fields like Name (name) and Email (email) [20].

Error Handling​

  • Implement robust error handling for the contact form [63].
  • Programmatically mark erroneous fields (aria-invalid="true") [62].
  • Provide error messages textually, link them to the field (aria-describedby) [65], and offer correction suggestions [70].
  • Announce error messages to screen readers via role="alert" or similar [77].

Miscellaneous & System-Wide Measures​

Help​

  • Provide a consistent help mechanism on all pages (e.g., link to FAQ/Contact in the footer) [60].

Documentation​

  • Create and publish an (honest) accessibility statement on the website.

If you implement all these To-Dos, your website will very likely achieve the presumption of conformity.

Conclusion​

A total of 55 individual criteria from WCAG 2.2 A and AA were checked, which are necessary for compliance with legal requirements [1].

  • Met Criteria: 35
  • Not Met Criteria: 20

The website exhibits severe deficiencies in terms of accessibility and is far from meeting the requirements of WCAG 2.2 AA [78]. The problems run through all four principles of accessibility (Perceivable, Operable, Understandable, Robust) [3]:

  • Perceivable: Missing text alternatives for images, insufficient color contrasts, flawed semantic structure that obscures relationships and information.
  • Operable: Important parts of the website (navigation, FAQ) are not keyboard operable, focus is not visible, moving content (slider, marquee) cannot be stopped, and a Skip Link is missing.
  • Understandable: Forms are not correctly labeled, errors are not communicated or inadequately communicated, and alternative navigation paths and consistent help are missing.
  • Robust: The incorrect use of HTML and the lack of ARIA where necessary mean that assistive technologies cannot interpret the page correctly.

This demo website is highly inaccessible in its current state. However, it illustrates typical barriers that can occur in real web projects very well. Implementing the listed To-Dos would require a fundamental overhaul of the code base, particularly the introduction of correct semantic HTML structures and the implementation of standard interaction patterns for navigation, forms, and dynamic content.

I hope this report helps you understand the identified barriers and shows the necessary steps for improving accessibility. Please feel free to contact me if you have any questions.

Liability​

  • No Legal Substitute: This audit does not constitute legal advice. All content and recommendations have been carefully reviewed and prepared to the best of our knowledge, but no guarantee can be given for completeness, timeliness, and correctness.
  • Responsibility for Implementation: The client is solely responsible for the proper, complete, and correct implementation of the recommendations.
  • Scope of Liability: Any liability is limited to intentional or grossly negligent conduct. In particular, claims for damages caused by slight negligence are excluded.

Should you have questions regarding the license scope, the use of the content, or liability, please feel free to contact me.

​

  1. W3C, “Web Content Accessibility Guidelines (WCAG) 2.2.” 2023. [Online]. Available: https://www.w3.org/TR/WCAG22/ ⤴
  2. Bundesministerium der Justiz und für Verbraucherschutz, “Gesetz zur Umsetzung der Richtlinie (EU) 2019/882 des Europäischen Parlaments und des Rates über die Barrierefreiheitsanforderungen für Produkte und Dienstleistungen (Barrierefreiheitsstärkungsgesetz – BFSG).” 2023. [Online]. Available: https://www.gesetze-im-internet.de/bfsg/ ⤴
  3. W3C Web Accessibility Initiative, “Understanding the Four Principles of Accessibility.” 2022. [Online]. Available: https://www.w3.org/WAI/WCAG21/quickref/ ⤴
  4. W3C, “G94: Providing short text alternative for non-text content that serves the same purpose and presents the same information as the non-text content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G94 ⤴
  5. W3C, “H37: Using alt attributes on img elements,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H37 ⤴
  6. W3C, “H67: Using null alt text and no title attribute on img elements for images that assistive technology should ignore,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H67 ⤴
  7. W3C, “ARIA10: Using aria-labelledby to provide a text alternative for non-text content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA10 ⤴
  8. W3C, “G141: Organizing a page using headings,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G141 ⤴
  9. W3C Web Accessibility Initiative (WAI), “W3C Karussell-Tutorial: Seitenregionen.” 2023. [Online]. Available: https://www.w3.org/WAI/tutorials/page-structure/regions/ ⤴
  10. W3C, “ARIA11: Using ARIA landmarks to identify regions of a page,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11 ⤴
  11. W3C, “ARIA16: Using aria-labelledby to provide a name for user interface controls,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA16 ⤴
  12. W3C, “H42: Using h1-h6 to identify headings,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H42 ⤴
  13. W3C, “H69: Providing heading elements at the beginning of each section of content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H69 ⤴
  14. W3C, “H48: Using ol, ul and dl for lists or groups of links,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H48 ⤴
  15. W3C Web Accessibility Initiative, “WAI-ARIA Authoring Practices 1.2.” 2021. [Online]. Available: https://www.w3.org/TR/wai-aria-practices/ ⤴
  16. W3C, “H44: Using label elements to associate text labels with form controls,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H44 ⤴
  17. W3C, “G57: Ordering the content in a meaningful sequence,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G57 ⤴
  18. W3C, “G96: Providing textual identification of items that otherwise rely only on sensory information to be understood,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G96 ⤴
  19. W3C, “G214: Using a control to allow access to content in different orientations which is otherwise restricted,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G214 ⤴
  20. W3C, “H98: Using HTML autocomplete attributes,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H98 ⤴
  21. W3C, “G14: Ensuring that information conveyed by color differences is also available in text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G14 ⤴
  22. W3C, “G170: Providing a control near the beginning of the web page that turns off sounds that play automatically,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G170 ⤴
  23. W3C, “G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G18 ⤴
  24. W3C, “G145: Ensuring that a contrast ratio of at least 3:1 exists between text (and images of text) and background behind the text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G145 ⤴
  25. W3C, “G142: Using a technology that has commonly-available user agents that support zoom,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G142 ⤴
  26. W3C, “C32: Using media queries and grid CSS to reflow columns,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/css/C32 ⤴
  27. W3C, “G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G206 ⤴
  28. W3C, “G17: Ensuring that a contrast ratio of at least 7:1 exists between text (and images of text) and background behind the text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G17 ⤴
  29. W3C, “G195: Using an author-supplied, visible focus indicator,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G195 ⤴
  30. W3C, “C35: Allowing for text spacing without wrapping,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/css/C35 ⤴
  31. W3C, “G202: Ensuring keyboard control for all functionality,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G202 ⤴
  32. WHATWG, “HTML Standard — The tabindex attribute.” 2024. [Online]. Available: https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex ⤴
  33. W3C, “H97: Grouping related links using the nav element,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H97 ⤴
  34. W3C, “G4: Allowing the content to be paused and restarted from where it was paused,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G4 ⤴
  35. W3C Web Accessibility Initiative (WAI), “WAI-ARIA 1.2: aria-live.” 2021. [Online]. Available: https://www.w3.org/TR/wai-aria-1.2/#aria-live ⤴
  36. W3C, “G21: Ensuring that users are not trapped in content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G21 ⤴
  37. W3C, “G133: Providing a checkbox on the first page of a multipart form that allows users to ask for longer session time limit or no session time limit,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G133 ⤴
  38. W3C, “G15: Using a tool to ensure that content does not violate the general flash threshold or red flash threshold,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G15 ⤴
  39. W3C, “G1: Adding a link at the top of each page that goes directly to the main content area,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G1 ⤴
  40. W3C, “G88: Providing descriptive titles for web pages,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G88 ⤴
  41. W3C, “G59: Placing the interactive elements in an order that follows sequences and relationships within the content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G59 ⤴
  42. W3C, “G91: Providing link text that describes the purpose of a link,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G91 ⤴
  43. W3C, “H30: Providing link text that describes the purpose of a link for anchor elements,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H30 ⤴
  44. W3C, “G125: Providing links to navigate to related web pages,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G125 ⤴
  45. W3C, “G64: Providing a Table of Contents,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G64 ⤴
  46. W3C, “G63: Providing a site map,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G63 ⤴
  47. W3C, “G130: Providing descriptive headings,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G130 ⤴
  48. W3C, “G131: Providing descriptive labels,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G131 ⤴
  49. W3C, “G165: Using the default focus indicator for the platform so that high visibility default focus indicators will carry over,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G165 ⤴
  50. W3C, “G210: Ensuring that drag-and-drop actions can be cancelled,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G210 ⤴
  51. W3C, “G208: Including the text of the visible label as part of the accessible name,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G208 ⤴
  52. W3C, “G213: Provide conventional controls and an application setting for motion activated input,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G213 ⤴
  53. W3C, “H57: Using the language attribute on the HTML element,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H57 ⤴
  54. W3C, “H58: Using language attributes to identify changes in the human language,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/html/H58 ⤴
  55. W3C, “G107: Using ‘activate’ rather than ‘focus’ as a trigger for changes of context,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G107 ⤴
  56. W3C, “G80: Providing a submit button to initiate a change of context,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G80 ⤴
  57. W3C, “G61: Presenting repeated components in the same relative order each time they appear,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G61 ⤴
  58. W3C, “G197: Using labels, names, and text alternatives consistently for content that has the same functionality,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G197 ⤴
  59. W3C, “G220: Provide a contact-us link in a consistent location,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G220 ⤴
  60. W3C, “G73: Providing a long description in another location with a link to it that is immediately adjacent to the non-text content,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G73 ⤴
  61. W3C, “ARIA19: Using ARIA role=alert or Live Regions to Identify Errors,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA19 ⤴
  62. W3C, “G83: Providing text descriptions to identify required fields that were not completed,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G83 ⤴
  63. W3C, “G85: Providing a text description when user input falls outside the required format or values,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G85 ⤴
  64. W3C, “ARIA21: Using aria-invalid to Indicate An Error Field,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA21 ⤴
  65. W3C, “Success Criterion 4.1.3 Status Messages,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#status-messages ⤴
  66. W3C, “G167: Using an adjacent button to label the purpose of a field,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G167 ⤴
  67. W3C, “Success Criterion 1.3.5 Identify Input Purpose,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#identify-input-purpose ⤴
  68. W3C, “Success Criterion 3.3.1 Error Identification,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#error-identification ⤴
  69. W3C, “G177: Providing suggested correction text,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G177 ⤴
  70. W3C, “G134: Validating web pages,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G134 ⤴
  71. W3C, “Success Criterion 1.3.1 Info and Relationships,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#info-and-relationships ⤴
  72. W3C, “Success Criterion 4.1.2 Name, Role, Value,” 2023, [Online]. Available: https://www.w3.org/TR/WCAG22/#name-role-value ⤴
  73. WHATWG, “HTML Living Standard.” 2024. [Online]. Available: https://html.spec.whatwg.org/ ⤴
  74. W3C, “G108: Using markup features to expose the name and role, allow user-settable properties to be directly set, and provide notification of changes,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/general/G108 ⤴
  75. W3C, “ARIA4: Using a WAI-ARIA role to expose the role of a user interface component,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA4 ⤴
  76. W3C, “ARIA22: Using role=status to present status messages,” 2023, [Online]. Available: https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA22 ⤴
  77. W3C, “WCAG 2.2 - 5. Conformance.” 2023. [Online]. Available: https://www.w3.org/TR/WCAG22/#conformance-to-wcag-2-2 ⤴
Portrait of Dmitry Dugarev wearing glasses in a black shirt and smiling

Best regards,

Dmitry Dugarev

Founder of Barrierenlos℠ and developer of the Semanticality™ plugin. With a master’s degree, over 8 years of experience in web-development & IT-Compliance at Big Four, Bank and Enterprise, and more than 1,000 web pages tested for accessibility for over 50 clients, I help web teams implement accessibility in a structured way — without months of redevelopment.

Do you want a clear roadmap for an accessible website?

Have your website checked for accessibility by experts → Receive a comprehensive PDF report with detailed explanations for each issue, along with 100+ clearly prioritized actions as a to-do list.

Discover Accessibility Audit now

On this page

Your privacy is important to us

We use cookies to improve your browsing experience and analyze website traffic. Choose which cookies we may use. You can find more information in our Privacy Policy.

These cookies are required for the basic functionality of the website and cannot be disabled.

These cookies help us understand how visitors interact with our website by anonymously collecting and reporting information.

  • Google Analytics: Collects anonymous statistics on page usage.
  • Hotjar: Analyzes click and scroll behavior to improve user-friendliness (anonymized).

These cookies are used to show you relevant advertising on other platforms and to provide content based on your interests.

  • Google Ads & Microsoft Ads: Measure the success of advertisements and enable personalized advertising.
  • Meta Pixel: Enables targeted advertising on Facebook and Instagram.
  • Affiliate Tracking (Freemius): Assigns purchases to a referring partner for commission settlement (30 days storage duration) - if you came to us via an affiliate link, these cookies must be activated for the partner to receive their commission.