Description

What is Web Accessibility?

Simply stated, Web accessibility means that people with disabilities can use the Web.

In the context of each website, that means that people with a wide variety of disabilities can perceive, understand, navigate, and interact with all of the site’s web-based content and applications.

Components of Web Accessibility

Web accessibility is the end result of an interaction between software applications, computer files and human behaviour.

The components:

• Developers are people who conceive, design, code, and write web content.
• Authoring tools are software applications that are used by developers to create and edit web content.
• Evaluation tools are software applications that are used by developers to evaluate web content according to various metrics (HTML validators, CSS validators, spelling/grammar checkers Web accessibility checkers, etc.)
• Web content is the web pages, web applications, etc. that the developers have created. Once these are finalized, they are hosted on a public web server.
• Users are the people, including people with disabilities, who access the content. In doing so, they must apply their knowledge, experiences, and in some cases, adaptive strategies (e.g. knowing to zoom-in if content is too small).
• Web browsers and media players are software applications used by users to access and render the web content. These applications may have accessibility features (e.g. keyboard navigation, zoom settings).
• Assistive technology are hardware devices (e.g. alternative keyboards, alternative mice, switches, etc.) and software applications (e.g.screen readers, screen magnifiers, scanning software, etc.) used by some people with disabilities to enable access to their computers, smartphones, etc.

What is an Accessibility Issue?

An accessibility issue is an aspect of some piece of web content that users with one or more disabilities will have disproportionately more difficulty using than users without disabilities, even when their web browser and assistive technologies work correctly. This differentiates accessibility issues from usability issues, which are problems affect everyone.

Examples:

• If an image is important to the message conveyed by a page and it does not have a text alternative, then screen reader users will not receive the intended message because when they reach the image, their screen reader will only read “Image” or may skip the image entirely.
• If a user interface component on a page can be interacted with by a mouse, but not by a keyboard, then keyboard-only users will simply not be able to operate the component and will not receive whatever information or other benefit the component provides.

Curb-cuts and Inclusive Design

Ensuring that a website is accessible will help to ensure that it can be used by people with a variety of disabilities. Moreover, websites that are designed for accessibility tend to be more usable for everyone. For example, a website that includes captions for its videos is accessible for users who are deaf and also usable by a hearing user in a noisy environment (e.g. a crowded pub) or quiet environment when headphones aren’t available (e.g. a commuter train). Features that have been added for accessibility, but that have mainstream use cases are often referred to as “electronic curb-cuts”.

In fact, it makes sense for web developers to think beyond the disabled vs. non-disabled dichotomy and instead to embrace inclusive design, whereby the design process considers the full range of human diversity with respect to ability, language, culture, gender, age and other forms of human difference. It recognizes that people and their needs are diverse and that what works for the average person doesn’t meet the needs of many individuals. When designed inclusively, web content can be accessible to everyone, including people with disabilities. The benefits of inclusive design often reach beyond helping a small group with unique needs, and instead benefit everyone!

The Role of a Web Accessibility Auditor

The role of the web accessibility auditor is to examine the web content using browsers, media players, evaluation tools, and assistive technologies in order to find accessibility issues and determine the likelihood that users with a broad range of disabilities will be able to effectively access the content.

As a web accessibility auditor, it is very important that you approach each piece of web content from this cross-disability perspective. Remember that the goal is for the web page to be as flexible as possible to as many different methods of use. As you work, continuously question whether you are making assumptions that might be undermining the cross-disability validity of your audit. For example, are you focussing too much on screen reader testing and not enough on issues that would impact low vision users (e.g. contrast, text resizability)? Or have you checked videos for captions, but not considered whether the video player can be operated with a keyboard?

Why Not Test with Real Users with Disabilities Instead?

The most comprehensive method of detecting web accessibility issues would probably be to test the web content with a truly representative group of real users with disabilities. To be truly representative, this group would have to:

• Cover all disability groupings: Web accessibility does not mean “works with screen readers”. To discover all of the possible accessibility issues through user testing alone, the user group would need to include at least the following disabilities:
  • visual disabilities including blindness, low vision, and colour-blindness. Low vision would be a particular challenge as there are many variations, from blurred vision to central field loss, to peripheral vision loss.
  • hearing disabilities including deafness and hearing impaired.
  • physical disabilities including no use of the hand and limited manual dexterity.
  • cognitive disabilities including a range of memory, perception, problem-solving, conceptualisation and attention deficits.
• Cover all of the adaptive strategies of these groups: Users with the same or similar disabilities may access the web differently. For example, some low vision users may choose to magnify the screen. Others may choose to change the colour contrast. Others may reduce the window width.
• Have enough redundancy to account for individual error: If a user testing pool contains only one user representing each disability (e.g. one screen reader users), then it may be unclear whether an issue that they are observed to encounter is actually due to the web content or if it is specific to that user (e.g. due to their own software setup, lack of knowledge or erroneous expectations).

Obviously, such a user truly representative testing setup would be extremely difficult and costly to arrange. Furthermore, because of the iterative nature of many software development processes, the testing would likely need to be repeated at least several times at even greater cost. Such a cost would be prohibitive for all but the largest and richest governments and companies.

Therefore, there is an important place for web accessibility auditors who can evaluate web content against widely accepted technical accessibility criteria that span the full range of accessibility needs. In Lesson 2, we will introduce WCAG 2.0, which will serve as these technical criteria.

That said, more limited user testing can still have a useful place in the software development process. For example, a screen reader user might be engaged to supplement an accessibility audit, especially where an auditor has spent a long time with a software product and perhaps become overly familiar with its idiosyncrasies.

Educating Others About Accessibility and Inclusive Design

The WCAG 2.0 document itself is quite technical, and parts may be difficult to understand without a lot of experience, but ultimately its purpose is to help developers in creating web content that anyone can access, so try to embrace this as your purpose as well!

Think of your report as educational material for designers, developers, QA testers and managers to learn about the general best-practices needed to support an inclusive web. Explain accessibility issues in a clear way, as they relate to the specific website that you’re auditing, but also to generally encourage designers and developers to create content that supports a practical, useable experience for people with disabilities and users in general.

---

Task

Choose 5 personas from the article, “An Alphabet of Accessibility Issues” (https://the-pastry-box-project.net/anne-gibson/2014-july-31) and for each persona, explain a potential accessibility issue that such a person might have difficulty with.

Post your completed task here, ensuring that the "Is this for an assignment?" dropdown is set to the name of this lesson.

---

Continue to Lesson 2 - Web Accessibility Guidelines »