Coding with Accessibility in Mind
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.
WCAG success criterion 3.3.2
Pointer input should be reversible.
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.
WCAG success criterion 2.5.2
Identify page language and language changes.
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.
WCAG success criterion 3.1.1
Structure information and relationships.
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.
WCAG success criterion 1.3.1
Establish proper reading order.
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.
WCAG success criterion 1.3.2
Visual and programmatic labels should align.
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.
WCAG success criterion 2.5.3
Provide meaning for non-standard interactive elements.
Use WAI-ARIA to provide information on function and state for custom widgets, such as accordions and custom-made buttons.
WCAG success criterion 4.1.2
Ensure that all interactive elements are keyboard accessible.
To be considered fully accessible, web content must be navigable by someone using only the tab key on a keyboard, ensuring proper keyboard focus.
WCAG success criterion 2.1.1
Avoid CAPTCHA where possible.
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.
WCAG success criterion 1.1.1