Developers play a key role in making websites and other digital assets accessible. Many accessibility requirements are technical and within the code itself. As soon as you begin writing code, it’s critical to incorporate accessibility standards following the Web Content Accessibility Guidelines (WCAG) 2.1 AA technical requirements.
Getting Started — Key WCAG Success Criteria for Developers
While there are 50 WCAG success criteria in WCAG 2.1 AA, if you start by focusing on just a few key improvements, you’ll make a significant impact on the accessibility of your website and other digital assets.
Associate a label with every form control.
With a form label, users know what input information to provide. Ensure enough information is included so the user can input the expected information without confusion.
Add a cancel and/or abort option, which means the user can move their mouse or finger to somewhere else and release with no effect. Another option is to actually provide the ability to undo the action or confirm they want to proceed with the action. This could be as simple as a confirmation pop-up.
With clearly identified page language, both conventional users and screen reader users can understand the text more accurately. The same goes for if the language changes–say from English to Spanish–different points in a document.
Structure your website so that content is read by a screen reader in the same way it’s presented visually. A good example is proper coding for headings.
Setting the reading order allows screen readers or text-to-speech technologies to read the information in a logical order. If information in the form of tables, figures and charts, for example, isn’t properly marked, a person using various assistive technologies may lose track of where they are in a document.
Some buttons, form fields, selectors and other interactive elements may have a programmatic label (label that is inside the code) that is slightly different from what visually shows on the website. One alternative to the exact same label is to start the label and text off with the same few words.
CAPTCHAs can be difficult for all users, especially people with disabilities, so determine if there is an alternative way you can filter out spam, bots, etc.
Make sure you have a minimum 3:1 color contrast ratio for user interface components and states and graphical objects that convey meaningful information.
This criterion addresses when receiving and then removing pointer hover or keyboard focus trigger additional content to become visible and then hidden.
Keyboard-only users must be able to navigate to and from all parts of a website. No mouse should be necessary to move away from any element of a website.
When a user interface component receives keyboard focus, the component and its focus indicator may not be completely hidden or cut off. What you need to know Among other users, people with ADHD or cognitive disabilities can benefit from always having the focus indicator visible to them. A focused element that’s hidden behind other page […]
When a user interface component receives keyboard focus, the focus indicator may not be hidden by author-created content. This is the AAA level of SC 2.4.12 (AA). This success criterion requires that none of the focus indicator is hidden. What you need to know Among other users, people with ADHD or cognitive disabilities can benefit […]
When an interactive element (link, button, form field, selectable element, etc.) receives focus, a visual indicator should show so the user can see what element they’re currently on.
Functionality that is activated by device or user motion, for example, shaking a device or signaling to a camera, should be able to be disabled and an alternative for equivalent activation should be available.
If any part of your website requires a dragging movement, provide an alternative means of dragging, such as tapping or clicking. What you need to know This requirement doesn’t apply to actions that are necessary to operate the user agent or assistive technology. Dragging does not require a particular path, only a starting and an […]
All interactive targets should take up at least 24×24 CSS pixels of space. This can include white space around the target. What you need to know Ensuring that targets are big enough and that there’s sufficient space between them makes it less likely that a user will accidentally activate the wrong control. Meeting this success […]
If you have a help option, make sure it’s consistently available and in the same relative place on each page. This will make it easy to find as users navigate your website. What you need to know Access to help mechanisms may be provided directly on the page or may be provided by a link […]
A cognitive function test to log in can only be required under limited circumstances. What you need to know According to W3C, a cognitive function test is a task that “requires the user to remember, manipulate, or transcribe information.” This could take the form of a username and password, doing calculations, or solving a puzzle. […]
If your website authentication requires a cognitive function test, make sure it has an alternative that doesn’t have such a test. What you need to know The AA success criterion 3.3.7 allows authentication by using object or content recognition (for example, check every box with a traffic light), but 3.3.8 level AAA doesn’t. Common identifiers […]
For all user interface components (e.g. forms, links, scripts, controls, etc.), the name and role of those components should be coded in. Any states, properties, and values set by the user should be able to be programmatically updated so browsers and assistive technologies recognize them and reflect those changes.
For steps in a process such as registering or completing a form, information that the user has already entered must be made available to them. In a nutshell, this success criterion helps users by not making them enter information more than once unless it’s absolutely necessary.
