When a website is built, especially one that uses some of the newer scripting frameworks like Angular or React, developers tend to focus on building something quickly. That practice leads sometimes to developers using less than perfectly semantic code, which is bad for accessibility. Most screen readers understand semantic code without much difficulty because it is logical and provides hierarchical structure. Sites built using division (<div>) and span (<span>) tags are not semantically based. Thus, there is a need for tools to access code failings from the perspective of a user with disabilities.
Disabilities occur in a variety of forms and the Web Content Accessibility Guidelines (WCAG) attempt to cover all of them. Accessibility has four primary goals to enable all people to navigate the Web: perceivable, operable, understandable, and robustness. Accessibility tools assess code for those attributes, although no one tool is perfect in all regards. Consequently, a developer must use a variety of tools to obtain a full picture on whether the code he or she has written will actually work from an accessibility perception. Additionally, the tools available depend on the Integrated Development Environment (IDE) in which one develops and the browser(s) in which testing occurs in most cases, although some tools are cross-browser, cross-platform, and cross-device medium.
Now to narrow the scope a bit. Working on accessibility with an Angular-based project and having worked with accessibility in PHP/WordPress-based projects, my focus will be on those tools that my team uses, namely the IDEs and browsers. As it is better to have code WCAG-ready before testing, let us start with IDEs.
Integrated Development Environments (IDE)
For those readers who do not know, an IDE, to quote Wikipedia, “is a software application that provides comprehensive facilities to computer programmers for software development.” They usually include a source code editor, build automation tools, a debugger, linting, and possibly code completion.
Microsoft VS Code
My team uses Microsoft’s VS Code for Angular development, which is both free – you read that correctly, Microsoft has a free tool – and cross-platform (macOS, Windows x64, and Linux x64). VS Code is probably the best tool for Angular development because it is the native IDE for TypeScript, which is the coding language in which Angular 2 and later is written prior to conversion to JavaScript. VS Code can be used in other languages as well via extensions. It natively recognizes HTML, CSS, and similar languages. VS Code, like many other IDEs, is extendable with extensions. This writer uses two accessibility extensions:
- 508/WCAG Compliance Prompter prompts the coder to review code for accessibility.
- Web Accessibility is far more useful, albeit not perfect. It primarily tests against HTML code and provides alerts for what might be lacking or makes suggestions for improvement.
JetBrains WebStorm
WebStorm is primarily a JavaScript editor that natively includes WCAG support. It supports Angular, Node, React, and Vue development, although it is not free – it is a subscription service that (at the time of writing) starts at $129 per year.
Browsers
The browserscape has changed much over the last few years, especially since the advent of the smartphone and its primary operating systems: Android and iOS. According to the W3Counter, the February 2019 browser distribution has Chrome with 62.5% across all platforms. Safari is second with 13.8% across macOS and iOS. Microsoft IE and Edge are a combined distant third at 7.0%, followed by Firefox at 6.3%, and Opera at 3.0%. Opera, however, rates as the second most standards-complaint browser after Chrome on desktops and ranges better on both tablets and mobile.
Chrome, Firefox, and Opera are cross-platform and mostly cross-device. Apple Safari only works with macOS, iOS, and their siblings. Microsoft Edge and IE only work on Microsoft desktops, laptops, and tablets (unless you run them in Virtual environment). Additionally, all browsers now have inspection tools, which is the best place to start. Chrome conveniently has the most tools for accessibility testing in the form of extensions. However, no tool is perfect and each has its quirks.
Chrome
Below are the tools most useful in Chrome.
- The Chrome Inspector: The tool is installed by default. It is accessible via right-click and selecting Inspect (Ctrl/Cmd + Shift + I). The tool includes tabs to view html elements, the console, sources, network, and related information. Inbuilt.
- ACCESS Assistant: The browser extension exists for Chrome, Firefox, and IE 11. It allows automatic and manual accessibility testing and will generate reports. However, it produces some false positives in single-page, non-traditional sites like those built using Angular, especially on items like Angular Material checkboxes. Not free.
- ACCESS Continuum Explorer: While created by the same company as the Access Assistant, Continuum is focused on “live reloading,” which is good for testing in development. It has two versions: Pro (not free) and a more limited Community (free).
- Axe: A tool by Deque, it works from within Chrome’s Inspector. It frequently catches things that neither the Assistant nor Continuum catches, but it has its own bugs, which include demanding landmarking of the html tag itself. However, it is worth it because it provides clues on how to fix real errors.
- Landmarks: Provides a visual map of page landmarks.
- Colour Blind: Provides the ability to preview a page in various color-blind modes, e.g. protanopia, protanomaly, deuteranopia, deuteranomaly, etc.
- WCAG Accessibility Audit: Produces a report showing what errors exist. Similar to Access Assistant, but provides more detail on some matters.
- Web Developer: Provides more general tools, but allows outlining of elements, highlighting of ARIA roles, view of response headers, and many other useful development information.
Firefox
Below are the tools most useful in Firefox.
- The Firefox Inspector: Unlike Chrome’s Inspector, Firefox has limited accessibility testing built into its Inspector, but it must be enabled.
- ACCESS Assistant: See above under Chrome.
- WAVE Accessibility Extension: The WebAIM tool catches a number of items that neither the inbuilt accessibility nor the ACCESS Assistant does.
Opera
Opera is a little different. It is a sweet browser, but no real accessibilities exist for it except Tenon.io, which requires a paid license. Otherwise, its inspector is the Google inspector, and it uses the Web Developer extension that is available for Chrome.
Safari
No accessibility extensions exist of which I know for Safari.
Microsoft Edge
Like Firefox, some accessibility tools are built into Edge’s Inspector. Otherwise, no extensions per se exist for Edge at this time.
Microsoft Internet Explorer 11
As noted above, the ACCESS Assistant is available for IE11. Its inbuilt Inspector does not have accessibility testing built into it.
Round Up
As shown above, VS Code is probably the best free IDE; although WebStorm may be a better IDE because VS Code is essentially Notepad+ on steroids. WebStorm is much more full-featured. Chrome is, in my opinion, the best browser for accessibility testing.
In conclusion, Google Chrome has the most accessibility extensions to my knowledge. Some are paid, some are free, and some have limited features until an unhindered version has been purchased. I hope this provides a good overview of IDEs and Browsers tools for accessibility testing. Please visit https://a11yproject.com/resources.html#software for more information regarding accessibility tools, and visit our other Artemis blogs for more about accessibility.