Accessibility Techniques

This sites gathers different techniques to create more accessible webistes.

Identifying Content

Accessible Names

An accessible name is a text that is programmatically associated with an element and that is exposed by the browser to assistive technologies via the accessibility tree. It should identify the element it is associated with in an an concise way. In contrast a label is the visible element that gets presented or displayed to users. ¹

Naming Principles

The accessible name must contain or be equal the label that is presented visually. ²
Interactive Elements must have an accessible name, while non-interactive elements sometimes also need accessible names, like duplicate landmark regions, tables, dialogs or groups ³
Non-interactive text-level semantic elements and generic elements like <div> or<span> elements should not have an accessible name. ⁴ ¹⁰
- It is possible to label lists wit aria-label, though support of that is not widespread. So it is always better to change your design to allow for visual labeling. ¹¹

Naming Method Hierarchy

There is a hierarchy of methods that gets used to commutate the accessible name. The following list defines the approximate order of naming methods that gets used by browsers. ⁵ The first method having the highest precedence, the last method having the lowest precedence. However the exact methods that get used differ between elements. For a exact and complete list of all elements and their naming methods see the source reference of this paragraph. ⁵

aria-labelledby:
- Can reference one or more HTML element ids, including it‘s own. The name is then concatenated from the referenced elements names in the order specified.
- The best use of aria-labelledby is on visible elements. But a common way of using this attribute as well is to create a hidden element that get used by aria-labelledby to create a label for the element. For example for <button> elements that only consist of a visible icon. This is a more robust way than using aria-label since it suffers less from the disadvantages of the aria-label attribute. ⁵
aria-label:
- Accepts a string that serves as the elements name.
- Does not get translated by most translation tools. ⁶
- Developers might forget to update aria-labels, since they are invisible. ⁶
- Some people even think of the aria-label as a code-smell. ⁸
Derive name from another element:
- Using programmatically connected elements like <label> for <input> elements or <caption> for <table> elements and so on gives the element an accessible name.
Derive name from an attribute (except title):
- This includes attributes like the alt attribute for <img> elements or the value attribute for <input type="submit"> elements.
Derive name from the elements content:
- Elements like <button> or <a> can use it‘s content if it is text or has an element with an accessible name.
- Many elements don‘t use this method to compute their accessible name. ⁵
- Careful: Text or icons added through pseudo elements will also get included in the name.
title attribute:
- Using the title attribute as means of an accessible name is currently not recommended, due to the lack of consistent support. ⁷

What naming method to use

Adrian Roselli among others uses this priority when naming elements: ⁶

Native HTML techniques, which includes
- Derive name from other elements
- Derive name from an attribute (except title)
- Derive name from the elements content
aria-labelledby pointing at existing visible text
visibly-hidden element content that is still in the page
aria-label

It is always the by far most accessible solution to use visible elements for accessible names. Before using hidden elements or the aria-label attribute, you should first reconsider if you design can be made more inclusive by adding a visible label. One example of this would be icon only buttons. It would be more inclusive if the button also had a visible text label permanently shown or at least on focus. ⁹

Sources

WebAIM: Decoding Label and Name for Accessibility © WebAIM
W3C: Label in Name (Level A) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
W3C: Info and Relationships (Level A) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
Scott Ohara: Name, labels, ARIA, what to do? by Scott Ohara
W3C: 4. Accessible Name and Description Computation is licensed under W3C Document License
Adrian Roselli: My Priority of Methods for Labeling a Control by Adrian Roselli © Adrian Roselli
24 Accessibility: The Trials and Tribulations of the Title Attribute by Scott O’Hara
Eric Bailey: aria-label is a code smell by Eric Bailey
Sara Soueidan: Accessible Text Labels For All by Sara Soueidan © Sara Soueidan
Practical Support: aria-label, aria-labelledby and aria-describedby by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
Scott Ohara: Results of labeling lists (and list items!) by Scott Ohara

Skip article

Accessible Descriptions

Accessible descriptions can help users further understand a component, by linking one ore more elements that describes the component in more detail.

Principles

Should best only be used on on interactive elements, like input, link or button elements, since the support on these elements is most robust.
But a useful use-case for aria-describedby on a non-interactive element is for dialogs or modals that pop-up. If the visible explanation text is associated to the dialog element, it will be announced to the user, when the dialog opens. ¹
The aria-describedby attribute is especially useful in forms, since assistive technologies are in "forms mode" which will only announce form elements. In addition many users use tabbing to navigate the form. If the description is not associated with the input element, this information can be missed. ¹
The descriptions should be short and concise.
The descriptions are always presented as flat strings of text. So semantics of lists, images or links for example get lost. So make sure it will be announced as expected.
Descriptive text may not always get announced by screen readers, depending on the screen reader, browser combination and version. This is why it‘s important that relevant information is not only accessible via the aria-describedby attribute but by other means as well, like visually displaying the information.
The most reliable way of referencing descriptions is to not reference a container element containing multiple text entries, like list items, but to instead reference each element separately. This is because some screen readers will only announce the container element, but not any descendants.

Sources

TPGi: Describing aria-describedby by Scott O‘Hara © TPGi – a Vispero™ Company
W3C ARIA: Form Instructions by W3C WAI Tutorial Contributors is licensed under W3C Document License

Skip article

Skip Links

A skip link is intended for users to be able to access the main content of the page directly without having to navigate other repeated blocks of content like site navigation‘s or advertisement blocks.

Basic Skip Link

A common way of implementing skip links is to create a link as the first interactive element on the page that links to the main content of the page. The link only needs to be visible when it is focused to meet WCAG 2.1. It is however preferable to have the link always visible. This enables for example voice recognition users to target the link. ² If you do decide to hide the link if it‘s not focused, make sure to only hide it visually and not for assistive technology users. See the hiding elements article for more information. If the link is only visible when it is focused it is also recommended to make the link very visual distinctive, since the link may only be visible for a short amount of time when tabbing through the page. ³

Additional Skip Link Techniques

Another implementation for a skip link can be to not only create one link but multiple links to each major area of the page. This can be helpful for very complex pages with many independent areas. ¹ But for most sites one skip link is sufficient. ³ In addition it can be helpful to create a skip link at the beginning of each repeated area to the content immediately after that area. ¹ This can be helpful for pages with a lot of content, to make the navigation easier.

When deciding if and which skip link techniques to implement, make sure that each used technique actually improves the usability. Unnecessary links will otherwise only create clutter that decreases usability. ³

Skip Links Versus Alternative Techniques

It‘s important to note that you do not have to implement a skip link to be WCAG 2.1 compliant, if you have another technique implemented. This could for example be using landmarks and a appropriate heading structure to identify the main content. ¹ While these techniques are sufficient to meeting WCAG 2.1, they lack native browser navigation support, which is why skip links are still recommended, as long as they are implemented in the way described above. ³

Sources

W3C: Bypass Blocks (Level A) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
W3C: Adding a link at the top of each page that goes directly to the main content area by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
WebAIM: Skip Navigation Links © WebAIM

Hiding Content

Skip article

Hiding Elements

There are different methods of hiding content, that have different use-cases depending on the user group you want to hide it from.

Hiding elements for All users

Using CSS: visibility: hidden; ¹ This method has the advantage of enabling animations on show or hide.
Using CSS: display: none; ¹
Using the HTML hidden attribute. It will not get hidden to assistive technology users, if the element is referenced by another element for example by the aria-labelledby attribute. It also has the advantage of working without CSS, like in reader modes and it does not create an additional reading stop. But be careful not to overwrite this by other CSS rules ¹

Hiding elements only for assistive technology users

There are multiple ways of hiding elements only to assistive technologies that can be used in different use-cases.

Hide non-interactive elements and it‘s children to assistive technologies

To hide an element and it‘s children use the aria-hidden=“true”attribute. Be very cautious when using only hiding elements for assistive technologies. Only do it when it improves the experience for users using assistive technologies, for example by removing redundant information. Always make sure that the removed information is still accessible through other elements. ⁶ Furthermore don‘t use the aria-hidden attribute on interactive or focusable elements, because the element will still be focusable and wil remain in the tab index. ² Also don’t use aria-hidden=“false” to expose the element to assistive technologies, since this also does not work reliably. A better way is to remove the attribute completely. ⁶

Hide (interactive) elements and it‘s children to assistive technologies

To completely hide non-interactive and interactive elements to assistive technologies use the inert attribute. This attribute will also cause interactive elements from not being focusable anymore and removes them from the tab index. Using inert is also better for assistive technologies then using a focus trap implemented in JavaScript, because the focus trap will not always trigger. For example screen reader users, that use the equivalent of tabbing with their reader will not trigger the focus trap. Make sure to visually indicate this state, since by default there is no special styling applied to inert elements. A common use-case for this is for the background of modals or loading indicators, where the content is still shown but is not interactive until the modal is closed or the loading process is finished. ⁷

Hide an element semantics to assistive technologies

To hide an element semantics without actually hiding it‘s content use role=“none” or role=“presentation". Both do exactly the same. But it‘s recommended to use role="none" since it meaning is more intuitive. This can be helpful to improve legacy code, like <table> elements that are only used for styling purposes. ²

Hiding elements only for sighted users

How you hide elements for sighted users depends on what elements you want to hide.

Visually hide textual elements

The most commonly used practice to do hide textual elements only visually is using a CSS class called visually-hidden that is defined like below. ⁴ Only use this technique for textual content and not for interactive elements. Since this can lead to users, who rely on assistive technologies where they touch an element to hear what is beneath them, to not see the elements. Tailwind for example also provides sr-only utility for this. ⁵

.visually-hidden:not(:focus):not(:active) {
  clip: rect(0 0 0 0); 
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap; 
  width: 1px;
}

Visually hide interactive elements

For interactive elements that need to be hidden like <input> elements, use code like below. The code creates an custom checkbox, that places the actual <input> element above the custom visual checkbox and hides it for visual users. ³

<label for=“check” class=“c-sustom-checkbox”>
    <input type=“checkbox id=“check”>

    <!-- custom checkbox, use aria-hidden="true" to hide it from the accessibility tree, 
         don‘t forget to style all states like focus, checked, unchecked, ... -->
    <svg width=“16” height=“16” aria-hidden=“true”>
        …
    </svg>
</label>

.c-custom-checkbox {
    position: relative:
}
/* position the input above the svg element and hide it visually */
.c-custom-checkbox input[type=“checkbox”] {
    position: absolute;
    opacity: 0;
}

Visually hide content that slides in

For content that needs to slide in from the edge of the viewport you can use use code like below: ¹

.element-class {
    position: fixed;
    left: 0;
    top: 0;
    transform: translateY(<element height>);
    transition: transform .2s ease-in-out;
}

.element-class:focus {
    transform: translateY(0em);
}

Hiding Borders and Outlines

Use border-color: transparent; instead of border: 0; or border: none;. ⁸
Use outline-color: transparent; instead of outline: none;. ⁸
- Make sure you know what you do when hiding a outline, since all interactive elements should have a focus indicator!
The reason why you should use transparent is that high contrast modes will still show them this way. If you completly disable them the will not show up in those scenarios. ⁸
The source also has a code example on how to fix this issue if you already implemented it the wrong way using the forced-colors media-query. ⁸

Sources

Scott Ohara: Inclusively Hidden by Scott Ohara
Scott Ohara: Know your ARIA: "Hidden" vs "None" by Scott Ohara
Sara Soueidan: Inclusively Hiding & Styling Checkboxes and Radio Buttons by Sara Soueidan © Sara Soueidan
A11Y Project: Hide content by Dave Rupert is licensed under APACHE LICENSE, VERSION 2.0
Tailwind sr-only utility
W3C: Accessible Rich Internet Applications (WAI-ARIA) 1.1 is licensed under W3C Document License
HTML Spec: Living Standard, 6 User interaction, the inert attribute is licensed under Creative Commons Attribution 4.0 International License
Frontend Masters: You Want border-color: transparent, Not border: none by Dave Rupert

Single Page-applications

Skip article

Adapting Single Page Applications

Singe page applications need extra considerations to be accessible. Following are some aspects that developers should keep in mind when using them.

Page Transitions

In single page applications the browser does not manage a page switch from one "site" to another within the application. This is why a transition that would otherwise be a new page load, must be implemented in a way that is noticeable and accessible to users that rely on assistive technologies.

Focus Management

When switching to a new "page", make sure to move the browser focus to an appropriate element. There are different strategies to where the focus can be moved:

Move the focus to the top of the page. So move it to the first meaningful element like the "skip-link". You may need to make sure that this element is indeed focusable using tabindex="-1". Otherwise the focus will move to a random element. ¹
For well understood multi-page processes like checkout steps in a web store, the focus can be moved directly to the main content. ¹
Make sure that the unique part of the page title and the <h1>main headline are identical and that the headline is focusable. Then you can move the focus to the main headline. ² ³

Page Titles

Make sure that each "page" in your application has a unique descriptive title, that gets updated whenever the page context changes. ¹ In addition it is recommended to announce title changes to assistive technology users, since assistive technologies often do not monitor title changes if there is no page load. ¹ There are multiple strategies to achieve the title announcements:

The third focus management strategy mentioned above effectively announces title changes: Make sure that the unique part of the page title and the <h1>main headline are identical and that the headline is focusable. Then you can move the focus to the main headline. ² ³
Create a fixed and visually hidden live region at the beginning or end of the HTML body like below, that gets used to announce the changed title. When the title changes, insert the title text inside the live region. After 500ms you can optionally remove the title text again to not clutter the DOM for assistive technology users. ¹ This method has the disadvantage of being more complex and error-prone. It is also increases the gap between visual users and assistive technology users, which should be kept as small as possible.

<div class=”page-title-live-region visually-hidden” aria-live=”polite”></div>

Browser History

Make sure to update the browser history accordingly to page changes, so that forward or backwards browser navigation works as expected, instead of closing the entire application. ¹

Page Content Updates

Single page applications are by design often more dynamic, which means, they update only parts of the content instead of reloading the whole page. Because of the dynamic nature of single page applications, the developer needs to make sure that changes to the content are announced to assistive technology users. So for example unexpected changes like form errors, should lead to the browser focus being moved to the error or error list. ² While expected changes like action confirmations should use live regions to announce the message without moving the focus. ²

Sources

Orange Digital Accessibility: Recommendations for Single Page Applications by Ricky Onsman is licensed under CC-BY-SA 3.0 © Orange SA

Testing

Skip article

Testing for Accessibility

You should test your site with automatic tools (like axe DevTools, ARC Toolkit, WAVE, ...). ¹
In additon you should manually test your sites to find errors that automatic testing tools do not find.
- To do so you can:
  - Go through the WCAG Guidelines and analyse the sites of your website agains the criterias.
  - Test the accessiblity and usability by:
    - Only navigating with the keyboard.
    - Using different screen-reader and browser combinations. (for example VoiceOver with Safari, NVDA with Firefox, Chrome or Edge, Talkback on Android)
    - Using the site zoomed-in and -out to see if everything scales as expected and that your site does not scroll in two directions as long as the viewport is wider than 320 CSS-Pixels for vertical scrolling and 256 CSS-Pixel high for horizontal scrolling.
    - Using a different font size (configured in the browser), to see if the font size scales up or down, as expected.
    - Using high-contrast modes of different operating systems/browsers.
    - Emulating vision and color deficiencies (for example with the Chrome Dev-Tools).
    - Disable CSS to see if your website works and is well structured.
    - Validate your HTML to see if it is fully parsable.
    - Check the heading structure
These tests should also be part of your development flow.
Last but not least, you should test your sites with real users with disabilities. These tests are very similar to typical usability tests with real users. ¹

Sources

Smashing Magazine: Testing Sites And Apps With Blind Users: A Cheat Sheet by Slava Shestopalov & Eugene Shykiriavyi

6 things I check on every website I build by Manuel Matuzović

States

Skip article

State Contrast

There are a few things to keep in mind when it comes to contrast when implementing states.

The indicator that visualizes a component to be in a certain state should have a contrast of at least 3:1. ¹
But it is not required that different states have a certain minimum contrast between them. But the states of cause need to be clearly differentiable. ¹

Sources

Non-text Contrast (Level AA) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License

Skip article

Focus Indicators

Focus indicators allow users to see where they are within the page by visually highlighting interactive elements, making it easier to navigate, interact, and understand the web interface without needing a mouse.

A visible focus indicator for interactive elements is required for a site to meet the Success Criterion 2.4.7: Focus Visible (Level AA). ¹
The indicator area that visualizes a component to be focused should have a contrast of at least 3:1. ²
The Success Criterion 2.4.13: Focus Appearance (Level AAA) mandates, that the focus indicator in addition needs to be "at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component". ³
- This means the area of the focus indicator must be at least 2×(2×height+2×width) or (4×width + 4×height). ⁴
- Based on this Criterion every pixel that has contrast of 3:1 or more between the unfocused and focused state can be considered part of the focus indicator area. For example if you already have a black 1px outline in the unfocused state you would need at least a 3px thick outline in the focused state.
- A keyboard focus indicator can appear in various forms. This Success Criterion suggests using a solid outline around the focused user interface element but also permits other types of indicators, as long as they are at least equally noticeable in size. ³
Sara Soueidan has an amazing in-depth article about this topic. ⁴
Do not set outline: none; or outline: 0; even if you use another method like box-shadows. Because high contrast modes will for example not show box-shadows and will overwrite the colors of the outline, but only if the outline is not set to none. They will also often keep the width of the defined outline. Therefore you should set the outline to outline: 2px solid transparent; if you don't use it to create your default focus indicator. ⁵
The default browser outlines often lack the required contrast and area requirements and often conflict the color palette of the website. Therefore it is recommended to define and test your own custom focus indicator styles that meet the WCAG Success Criteria. ⁴

Sources

Focus Visible (Level AA) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
Non-text Contrast (Level AA) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
Focus Appearance (Level AAA) by Accessibility Guidelines Working Group (AG WG) Participants is licensed under W3C Document License
Use transparent borders and outlines to assist with high contrast mode by Andy Bell

Wcag

Keyboard Accessibility

Websites should be keyboard accessible according to WCAG2.2. This article discusses some aspects of this requirement.

Should Keyboard Accessibility be implemented for mobile devices

According to the Guideline 2.1 of WCAG 2.2 websites need to be keyboard accessible for mobile devices as well, since this ensures that users can use a wide variety of assistive technologies that create simulated keystrokes as their output (e.g. voice controls). ¹
Success Criterion 2.1.1 states that "Everything can be done with a keyboard except freehand movements.". The authors of the article further explain that most gestures that are done by pointing devices should also be made keyboard accessible like clicking, selecting, moving, sizing. ²
Further they elaborate what can be interpreted as freehand movements which can be exempt from the requirement for keyboard accessibility: "However, there is a small class of input that is done with a pointing device that cannot be done from the keyboard in any known fashion without requiring an inordinate number of keystrokes. Free hand drawing, or watercolor painting require path dependent input. Drawing straight lines, regular geometric shapes, re-sizing windows and dragging objects to a location (when the path to that location is not relevant) do not require path dependent input." ²
But this does not mean that every control needs to be accessible via keyboard interfaces, but that there must be at least an alternative to achieve the same or a comparable action. ²
Note that the AAA level Success Criterion 2.1.3 requires that all pointer actions have a keyboard accessible equivalent. ³

Autofocus

The autofocus global attribute is a Boolean attribute that specifies an element should automatically receive focus when the page loads or when the it belongs to is displayed.
Generally, it's best practice not to use the autofocus attribute. Automatically focusing on the first form field can be problematic for users with screen readers or on mobile devices, as it can cause them to miss important context or feel like they're losing control of the web browsing experience.
That said, it can in some limited cases be beneficial to use it. If you can answer these questions with "yes" your users might benefit from you using the autofocus attribute: ⁴
1. Is there a single component that all users will focus on when the page loads?
2. Does the component appear at the beginning of the page?
3. Will implementing autofocus improve the user experience?
4. Is the operation of the component unambiguous?
5. Could autofocus cause the page to scroll automatically when viewed on smaller screens?