Ensuring users of assistive technologies have trouble-free access to your website
What does WCAG 4.1.2 say about supporting assistive technologies?
Many people with disabilities rely on assistive technologies (AT) of various types, including screen readers, screen magnifiers and braille displays. These technologies work without issues when websites use standard controls and interface elements.
However, if your website has custom controls, or if interface elements are coded or scripted to play a different role than usual, this can leave users of AT unable to fully interact with your website.
The W3C’s Web Content Accessibility Guidelines (WCAG) addresses this digital accessibility issue in guideline 4.1.2 on Name, Role, Value. To conform with this success criterion, you need to share vital information about the role, state and value of custom interface components and controls with AT and make it possible for AT to control them.
Why is this success criterion important?
If you customize the controls on your website, or program interface elements to work in a different way than is usual, you risk breaking functionality and creating unexpected behavior for users of AT. For example, an AT user might lose keyboard control in standard elements or be unable to see where the focus is on the page or whether a checkbox is ticked.
Not everyone with a disability relies on AT, but there are many millions of users around the world in this community. Shutting them out of functionality on your website or making their experience second-rate will likely translate into missed revenues and decreased loyalty. It could also put you at risk of a digital accessibility lawsuit under legislation such as the Americans With Disabilities Act (ADA).
What can I do to fix the issue?
If your website uses standard controls from AT, it is likely already to meet the necessary conditions for conformance with WCAG 4.1.2. But if you employ custom controls or have programmed interface elements to play a different role than normal, you will need to provide additional information on the state of user interface controls to AT. You will also need to ensure that your custom controls can be controlled by AT.
The key action you need to take is to fully define the names, roles and values of all user interface components — which ensures that this vital information is passed to AT. There are a number of techniques for conforming with this success criterion, including the use of aria-describedby to associate formatting information with elements on the page. Another example is the use of aria-expanded on your button menus. Set it to true when open; false when closed.
This digital accessibility issue can be diagnosed automatically, but remediating all instances will require a combination of automated and manual work. AudioEye combines automated scanning and remediation technology with human-led testing and custom remediation, providing a unique hybrid service that resolves accessibility issues on an ongoing basis. By subscribing to the AudioEye service, you get the benefit of rapid identification and remediation of this and other key accessibility issues.
Don’t delay — subscribe today and solve your digital accessibility issues with AudioEye.
Ready to see AudioEye in action?
Watch Demo
Ready to test your website for accessibility?
Share post