When remediating accessibility issues in an existing project, making additions is usually accepted without hesitation. If asked to add text alternatives, visual elements, instructions, or captions to a video, there is rarely a conflict. Even applying complex ARIA (Accessible Rich Internet Applications) patterns is never frowned upon.<\/p>\n\n\n\n
However, sometimes remediation requires rethinking some components, altering them, or rejecting some existing implementation. And this causes more friction.<\/p>\n\n\n\n
This is understandable, as remediation requires admitting that something is wrong (in terms of accessibility) and has to be done again. These types of changes can make a project go over its timeline.<\/p>\n\n\n\n
Accessibility is all about meeting a standard, and some of the criteria are very specific and don\u2019t allow discussion. So it\u2019s not always just a question of \u201cadding more.\u201d<\/p>\n\n\n\n
ARIA is a good example of this. There is a collection of attributes and existing patterns we can use, but in very specific ways. One principle is that \u201cNo ARIA is better than Bad ARIA,\u201d meaning that a bad implementation can be worse for users than no implementation at all.<\/p>\n\n\n\n
When planning accessibility from the start, a minimal approach is optimal. For example, some HTML elements have implicit ARIA roles and attributes. Native HTML form elements in the browser use implicit ARIA attributes like aria-checked. Using proper semantic elements (<head>, <main>, <footer>, <nav>, or <article>\u2026) adds many implicit ARIA roles to the structure of a site.<\/p>\n\n\n\n
It is an old joke that the first page ever on the World Wide Web was already accessible because it\u2019s just plain HTML with no images or styles. As with most jokes, there is truth at its core. The way different browsers implement HTML components follows strict standards, so a consistent industry-wide implementation will likely improve a custom one (if it\u2019s an option).<\/p>\n\n\n\n