Accessibility – WCAG, Usability & Design by Irfan Ali Princeton
Testing web sites and applications for accessibility, particularly those related to educational content, is a complex process that involves not only evaluating the strict application of WCAG and WAI-ARIA standards but also determining whether an interface is actually usable by someone with a disability, taking account a range of disabilities and assistive technologies. With educational content, for example, Science, Technology, Engineering, and Mathematics (STEM), interaction and content complexity can go well beyond what is typically evaluated in commercial or governmental web sites. Rather than making simple recommendations to retrofit an existing application to bring it into conformance with WCAG, for example, we must evaluate the application as a whole, bearing in mind the overall design goals, for example, in education, to demonstrate, interactively, a principle of mathematics or biology. The combination of the content and the interface used to interact with it can be significantly more challenging when factoring in the use of a screen reader, for example: One challenge can be timing of accessibility testing. When accessibility testing is introduced late in the development process, well after major architectural and development approaches are decided, discovery of accessibility or usability issues can be more difficult to resolve, especially if significant software changes are required. At this point, there may be no magic wand solution for making the content accessible. While WAI-ARIA is often seen as a way to make code accessible, applying it in complex interactions can be time consuming and potentially costly depending upon the structure of the underlying code, and it may fall short in addressing all identified obstacles. More difficult still is making changes to the overall interaction design or visual presentation, if accessibility testing reveals fundamental problems there. The time to think about accessibility is at the beginning of the process – at the design stage, and to evaluate accessibility throughout the software development lifecycle.
An additional challenge to accessibility evaluation is the myriad of frameworks and different sets of technology-stacks that are being used by development teams. User interface frameworks, whether commercial or open source, have varying levels of accessibility support. Accessibility needs be considered up front in the design process, and decisions revolving around which framework to use must be made with accessibility in mind. Claims that libraries or frameworks support accessibility or have specific accessibility features should be verified carefully, with respect to the version of the software to be used. Further, the target environment for the application, for example, which browsers and assistive technologies are required to be supported, will influence tool and design selection. It can be argued that accessibility testing should be conducted on the software development frameworks themselves to ensure that they can be successfully used to develop accessible applications.
Accessibility Tips for User Interface Designers
To create an optimally accessible experience, start early, in the application user interface and content design process. Here are some basic guidelines for every designer:
- Plan Heading and Semantic Structure Early: Ensure that all content and design fits into a logical heading or region structure.
- Consider Reading Order: The reading order should be the same as the visual order
- Understand the challenge of navigating non-visually: Ensure the structure supports efficient navigation between critical areas which a user may have to refer to in order to complete.
- Provide Good Contrast: Be especially careful with light shades of gray, orange, and yellow and ensure that selected colors meet the ratio mandated by the WCAG guidelines. See https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast- contrast.html
- Avoid Images of Text: Use actual text, rather than an image of text. It enlarges better, loads faster, and is easier to translate. Use CSS to add visual style to the text.
- Use Caution When using Capital Letters: All caps can be difficult to read for some users and can be presented incorrectly by screen readers
- Use Adequate Font Size and Remember Line Length
- Make Sure Links are Recognizable: Differentiate links in the body of the page withunderlines or something other than color alone
- Design Focus Indicators: Ensure that interactive controls, such as buttons and links, have a clearly discernable focus ring. Sighted keyboard users rely on focus indicators to identify location. Never consider a design where you disable the default focus indicator.
- Design a “Skip to Main Content” Link: Place a keyboard accessible link for users to skip navigation at the top of the page
- Do Not Convey Content with Color Alone: Some users can’t distinguish colors or mayoverride page colors
- Design Accessible Form Controls: Ensure form controls have descriptive labels, instructions, and validation/error messages
- Provide a design for responsive layout: Ensure that you provide a design to accommodate content in a responsive layout, so that a user who needs to enlarge text on the page can do so without having to scroll horizontally to read the end of each line.
Accessibility Tips for Developers
We had identified some basic tips for developers that focus on factors that can influence overall accessible user experience. Bringing accessibility expertise into the development process and to have subject matter experts embedded or readily available can avoid many issues.
Tools and Frameworks
Selecting the Right Framework/Widget Library is critical. Common frameworks may have components and widgets with built-in accessibility, but we have found cases where documentation did not accurately describe accessibility support or did not provide adequate documentation on what developers would be required to do to implement accessibility features effectively. Further, stand-alone components may be accessible in a test case, but when integrated into an application can introduce accessibility issues. When framework issues are found, it is critical to file a bug with the vendor or open source project owner. But if a fix is not forthcoming, seriously consider whether the framework itself is the right choice. We highly recommend identifying and using accessible widget libraries with robust components.
Application performance can seriously affect accessibility. A poorly performing application can cause lag time that may be confusing to some users, particularly those who rely on screen reading software. Backend developers should tune up performance, and performance should be managed properly on both the back end and front-end layers to ensure low latency for application loading and functions. Here are some basic performance guidelines for developers:
- Browser Caching: Leveraging the browser cache is crucial for assets that are rarely changing. In such cases, a maximum-age of 7 days is recommended.
- Reducing the HTTP requests: Developers should minimize the number of HTTP requests
- Error Handling: In case of an error while accessing the application, provide the user with a link or proper information that, for example, provides contact information for customer/end-user support
- Database Optimization: Whether it is a cleaning out old unused tables or creating indexes for faster access, there are always things that can be optimized
As a general rule, when content within the page is updated dynamically, the user should be given control over those content updates, for instance by activating a link or button. If content updates automatically without user intervention, there is a risk that users of assistive technology will miss that changing information or be confused by it. That is, if an element that currently has focus is removed or significantly changed, keyboard focus may be lost, sometimes reverting to the top of the page, thus disorienting a screen reader user.
Status updates as an example, if a page displays updated data every 10 seconds, it’s quitepossible that the automatic content updates will not be accessible to screen reader and keyboard users. And worse, the rest of the page content may also be inaccessible because the user cannot reach it without first encountering the dynamically updating content.
Using WAI-ARIA, the developer can identify content that dynamically change as a live region. A live region allows for the presentation of content updates in a way that is appropriate for a screen reader user. It allows the developer to control the level of interruption (assertive or polite, etc.), the kind of information that is presented (additions, deletions, etc.), and how much of that information to present.
When using live regions, early testing with screen readers will be essential to confirm that the updates are announced as intended.
Irfan Ali is an UI architect and accessibility engineer from Princeton, New Jersey. You can follow him on twitter @thea11Y