We talk a lot about velocity here at RedMonk. Successful companies know that to appeal to all tiers of an organization–developers and CIOs alike–they need to support rapid development and deployment. As Jim Rose, CircleCI’s CEO, told my colleague James in 2019: “In the US the key driver is speed. Move faster!” But this truism may seem to run counter to the paired need to make apps more accessible. The process of adding alt tags to images and ensuring a webpage can be tabbed through places an additional burden on software engineers while extending the time it takes to bring client-facing products to market. How can companies ensure their products accord with Web Content Accessibility Guidelines (WCAG) without sacrificing speed? The answer isn’t easy.
I will be thinking about speed in two distinct ways: first, the velocity of the application development process itself, and second the speed of the site itself.
One way that organizations have elected to make their apps accessible without incommoding developers is by purchasing a JS overlay like accessiBe (a market leader in this space), AudioEye, FACIL’iti, or Max Access. Instead of altering the markup, these plugins add a new layer of JS that interprets the site. But by hijacking the HTML’s visibility these overlays hinder screen readers from navigating the page and identifying elements like h1 tags. Moreover, this additional JS may cause the app to slow down or crash. There have been so many problems with these technologies that most accessibility advocates strongly oppose them. The A11Y Project, a community committed to promoting inclusive and accessible digital experiences, “does not recommend using permanent overlay plugins.” Moreover, as Forbes reported last year, the National Federation of the Blind argues that “accessiBe peremptorily and scornfully dismisses the concerns blind people have about its products and its approach to accessibility.” Automated overlays are workarounds that do not provide a satisfactory substitute to semantic markup.
The industry’s focus on velocity has tended to focus on application creation, but speed of execution and raw performance is vital as well. Google announced that it will now use site speed in web search rankings, but this determination may run counter to best practices for app accessibility. Semantic markup is the gold standard for screen readers and other accessibility technologies, but it takes up a greater number of bytes than leaner code. This means that businesses more concerned with SEO rankings than inclusivity–and it’s difficult to fault anyone for wanting their business’s website to be as discoverable as possible–may elect to preference discoverability over accessibility. As the monolith of search, Google’s policies are in danger of pushing those otherwise amenable to accessibility best practices to shy away from it entirely.
The accessibility landscape is shifting fast, with new strategies, approaches, and challenges appearing constantly. However, the industry’s reliance on speed should never set back conventions outlined by the WCAG. Here are a few future-proof practical guidelines for those interested in app inclusivity.
- Avoid JS overlays. There is no silver bullet for automating accessibility; some manual markup is absolutely essential.
- Tab through the website. If you can’t access parts of your app using the keyboard alone, this means that screen readers can’t either.
- Prefer semantic markup. Although there may be some SEO penalty, this limited consequence is worthwhile to ensure inclusiveness. Hopefully someday soon Google will find a way to reward accessible sites with search preference.
- Make accessibility a part of your company culture. Don’t just play lip service to accessibility or, worse, only incorporate accessibility to avoid lawsuits. As Ben Fletcher showed us during his 2019 Monki Gras presentation, the Financial Times made inclusion a part of their culture by having employees learn sign language.
To hear more about accessibility in tech see more talks from RedMonk’s 2019 Monki Gras conference.
Disclosure: CircleCI and Google are RedMonk clients.
No Comments