Accessibility Acceptance Level

In an ideal world, all projects would strive for the highest level of accessibility possible; however, there are often extra factors that mean this is not always possible. The first thing to do is determine the appropriate level of conformance. Each project will vary based on several factors including which country the users are in and the users that the app serves. Notwithstanding, it’s important to remember that reaching a higher level of accessibility than what the current demographic requires will open up the application to use by a currently unserved user base. Demographic research and guidance from your legal or compliance team at this juncture will help determine what an appropriate level of conformance is, and if there are any additional legal requirements that need to be fulfilled. We will focus on WCAG conformance only. See Chapter 2 for more details on the WCAG conformance levels A, AA, and AAA.

Once a level is chosen, a baseline assessment of the application can be done to determine what will need to be fixed and the amount of work it will involve. To determine what needs to be tested and how to best perform that testing, the supported browsers and assistive technologies will also need to be chosen.

Browser Support

Browsers have different rendering engines and intricacies as to how they implement the HTML, CSS, and JavaScript specifications, which may affect the available features. Because of this, the same code can have different behaviors depending on which browser it is rendered in.

As of December of 2018, the market was divided as shown in Figure 4-1.

When looking at device specific market share the stats change a little for desktop and mobile as shown in Figures 4-2 and 4-3.

With a device distribution showing a pretty even split between mobile and desktop. See Figure 4-4.

Understanding the usage trends for the specific application can help guide decisions based on what they are using.

Assistive Technology Support

Just like browsers, assistive technologies may work in different ways even if they are the same type. For example, JAWS and NVDA, both screen readers, have their own implementation and often exhibit different behaviors when run on the same code.

Typically, a screen reader works in combination with a standard web browser, which can yield a large number of possible combinations. According to a WebAIM survey from October of 2017 the most common screen reader/browser combination was JAWS with Internet Explorer. Figure 4-5 shows a more detailed breakdown.

Unlike browser and device versions and types, screen reader usage cannot just be detected via analytics. Even if we could, there are some serious privacy and ethics considerations regarding this kind of data as it could easily be used in order to discriminate against disabled users. User research is currently the best and most ethical way to understand what assistive technologies users are utilizing and how.

Flows and Processes

Procuring a site map for all pages and flow diagrams for processes will ensure that each activity can be tested and properly evaluated. Access roles are a factor in this as well if the site has content that is only displayed for certain types of users or only if certain conditions are met. Understanding how to get to each piece of content will make testing easier and more effective. Good product documentation will help tremendously in any accessibility initiative.

When enumerating the pages and processes to test, it’s important to keep in mind that at least some of the assessment work will likely be performed by someone not familiar with the application. It is also important to identify areas of functionality that are only available based upon specific data being in place.

For the application to be considered conformant, key features and all pages comprising the steps for accomplishing the end goal of the feature must be conformant. Having a list of these features and their steps is paramount so that they all can be checked for accessibility issues. Taking an ecommerce site as an example, selecting products, adding them to a cart, reviewing the cart, and checking out, all need to be accessible for the site to be considered accessible. If any part is nonconforming, then the site does not meet conformance standards.

Third-Party Integrations

If the application uses third-party elements such as libraries, external components, or content management tools, research regarding their accessibility support, capabilities, and limitations will be necessary. If any of them cannot be made conformant and replacement is impossible, then alternate flows or partial conformance will need to be considered for those elements. Documentation from third-party tools can be a great source of guidance for how to achieve the necessary conformance. Many third-party integrations will provide implementation instructions for achieving accessibility while utilizing their product. For example, Angular Material does this through notes at the bottom of their component overview pages and in their Component Dev Kit (CDK) documentation (Figure 4-6).

Breakpoints

Especially with the current mobile-first trend, many applications are now built in a responsive manner as it makes it easier to scale up content then to try and create a mobile view once the larger views have been created. A responsive web site is characterized by using web technologies such as HTML, CSS, and JavaScript to resize, hide, or rearrange content based on the size of the viewport (browser or device window) in which the content is being displayed. The goal is to make the site look good regardless of device or window size. To achieve this, breakover points are set at which display behavior changes. Figures 4-7 and 4-8 show the same web site when the window is 1024 pixels wide (Figure 4-7) vs. a viewport of 500 pixels wide (Figure 4-8).

In this CSS example, when the viewport size is greater than or equal to 500 pixels, buttons will have a blue background (Figures 4-9 and 4-10).

In this way, viewport height and width, screen resolution, and device orientation can be targeted. Because the UI changes based on the device and viewport size, there is a potential for accessibility issues to be found only when within certain viewport size ranges or screen resolutions. Imagine this scenario if the button text color is also blue – it would be invisible for some users, but only those using specific viewport sizes. It is therefore important to know where these breakpoints are in your application to make sure testing is done for each interval or use case.

Animations and Movement

Any content that conveys a sense of motion should be assessed. This can be a loader, video, synchronized media presentations (such as time-based interactive components and slideshows), animations, tickers, etc. Context, purpose, and implementation factor into how animations and moving elements should be handled, often aspects that cannot be tested via automated tooling. In general, support should be provided to start, stop, pause, or bypass any such content.

Keyboard Accessibility

The ability to reach all content via keyboard is essential to accessibility. Many users with motor disabilities and vision impairments rely on keyboards (or other nonpointer devices) to navigate web sites and applications. Common potential issues include lack of focus indicators, focus traps, and tab order. Voice navigation (such as with a screen reader) may also be impacted by a lack of keyboard accessibility. Additionally, because screen readers often provide their own keyboard shortcuts, it’s important to test keyboard accessibility both with and without a screen reader active to ensure access to all.

Focus Indicators

Although having style changes when an item is hovered over (with the mouse over the element) is quite common, having some indication of where the current focus is (selected element, typically by using the tab key), is much less common. Many browsers have defaults built-in for focus that are often user configurable but are often overridden for stylistic purposes and not replaced. Figure 4-11 shows a focus highlight in Firefox on the author’s computer.

In the preceding example, the focus is in the date field. It is important to note that the focus is denoted by more than just color. The outline width is also increased. This ensures that the focus will be visible even if the user is color blind.

WCAG References

• Success Criterion 1.4.1: Use of Color

• Success Criterion 2.4.7: Focus Visible

Tab Order

When going through a page focusable items (links, buttons, and form fields) need to be attainable while using only the keyboard. Focus should be able to be shifted from one to the next by hitting the “tab” key in order as they appear on the screen. In Figure 4-12, when tabbing through the form, the order should be

1. 1.

   Name input

    
2. 2.

   Date input

    
3. 3.

   Submit button

    

WCAG References

• Success Criterion 1.4.1: Use of Color

• Success Criterion 2.4.3: Focus Order

Color Contrast

Even though color contrast testing is based upon mathematics and can easily be automated, color choice can often be a point of contention between designers or brand managers and accessibility testing. Making sure that brand specifications and style guides allow for the ability to meet color contrast conformance can help reduce friction in future projects.

Furthermore, even when minimum color contrast minimums are achieved, it is important for color to never be the only differentiator between states. When color has a meaning, such as using red for error messages, the meaning also needs to be indicated by something else than color. Icons can be very helpful in this situation. See Figure 4-13.

Video and Audio Content

If the application contains video or audio content, these will require some combination of transcripts, audio descriptions, or captions based on the content.

Transcripts are a text-only version of the media’s audio track, typically in document form. They can be used in multiple ways. They can be read either on screen or through assistive devices such as refreshable braille readers and screen readers. But they can also be searched and can be used for a quick glance to get an idea of what the media is about, or even for foreign-language translations.

Audio descriptions are a little different from transcripts. They are narrations added to describe important visual information that would not otherwise be conveyed via the transcript or context. For example, information about actions, or on screen text which would not normally be announced.

Captions are a text form of the audio information that is displayed on-screen, synchronized with the corresponding audio. They make audible content available to those who do not have access to audio and help users with comprehension as it allows the user to see the content as they hear it. Captions are essential when the visual information displayed in the video is tightly coupled to the audio track.

Although some automated testing tools can detect if these exist, what they cannot test for is if they are accurate and complete. Human testing will be necessary to verify that transcripts, audio descriptions, and captions are accurate and informative.

Additionally, audio content that plays automatically for more than 3 seconds should be pausable and/or have volume controls. The quality of the recording should also be assessed for background noise levels to ensure speech is easily discernible and understandable.

Alternate Text

Making sure that descriptions are relevant and convey all needed information is important to make sure users relying on them aren’t missing out on any content. If text is included in the image, it should also be included in the alternate text description.

Most automated accessibility testing tools will be able to determine if the “alt” attribute is present on images but will not be able to test the quality of the description. This will have to be evaluated manually for each image. They also cannot determine the content of the image. Text content should not be presented as images unless the presentation of the text is essential to understanding the text, such as a logotype, or can be customized by the user. Note that even for decorative images an empty “alt” attribute must be provided and not simply omitted. This signals to the screen reader that the image is there for aesthetic purposes only and can be ignored.

Touchscreen Gestures

For many users, gestures such as swiping left and right, pinching to zoom, and even tapping to select are difficult or even impossible to execute. For example, a shake gesture would be incredibly cumbersome, if not impossible, for a user who has their device attached to their wheelchair. Gestures also have issues with discoverability, including a lack of on-screen indicators to signal that they exist. If the application includes gesture-activated actions, instruction on what the gestures are and what they do should be available to the users, and alternatives to gestures should be included in the app.

Internal Audit

The preceding list of initial assessment considerations is not all-inclusive but is a good start to identifying the scope and nature of work, and determining what may need cross-department collaboration. If conducting an audit of the application internally it is still essential to have an accessibility expert to guide the testing and make sure that nothing is overlooked. Depending on the testers’ accessibility experience, training may be required.

External Audit

External audits can be very beneficial because they provide an external set of eyes on the application and are done by experts who have extensive knowledge of assistive technologies and accessibility needs. These audits also gain the benefit of impartiality.

External audits are usually performed on a representative subset of pages with the understanding that findings will be applied to all pages. This provides a good base for what to look for everywhere in the application. Making sure that critical processes and pages of the application get included in the audit will help ensure accessibility of the application.

The audit usually generates a report for each page that includes a list of errors with which guidelines or criteria the error references. Resolution suggestions are sometimes also included.

Automated Testing

Some portions of testing can be done via automated tooling. These tools can be run via the command line, added to development and continuous integration pipelines, API based, or run as browser plug-ins.

One example of a browser plug-in tool is the Lighthouse⁸ audit built into the Chrome developer tools. Lighthouse can audit more than just accessibility; it is therefore important to note that the accessibility checkbox is selected in the audit list. See Figure 4-14.

When running an audit with automatic tooling, most will give a list of errors which include the violation, where in the code it appears, and a link to documentation which usually references the specific requirement and success criteria being violated.

In addition, some tools will also list what they were unable to test for that will require manual testing (Figure 4-15).

A list of additional testing tools can be found on W3C WAI’s Web Accessibility Evaluation Tools List at www.w3.org/WAI/ER/tools/ .

Validators

HTML that is coded following the HTML specification is an important first step to making the website or web application accessible. Accessibility becomes hindered when styles and scripting are added without consideration of user needs. Making sure that the application’s HTML, whether written or generated, follows the HTML specification can help resolve issues right from the start. Markup validators can be used to automatically check the code.

Notice the warning for the language attribute in Figure 4-16. It was flagged as an accessibility error in Figure 4-15.

User Feedback

No matter how many automated tools are leveraged, user testing and feedback are still critical to ensuring that all content is usable. Whether accessibility is being assessed internally or by an external agency, it is important to verify that any resolutions made to correct accessibility shortcomings were effective. Even if all the specifications and rules are followed to the letter, a page or interaction may not be clear. It is therefore critical to solicit user feedback and to provide them with an avenue to do so when they are engaging with the application.

At the end of the day, all of the tools and specifications exist to help guide an application in the correct direction. Conformance is a matter of documentation and best effort, but true accessibility exists only within the ability of each and every user to access information and accomplish tasks.