Web Accessibility
The Equal Opportunity Web
An Introduction To Accessibility Standards
Overview:
1. Web Accessibility Around The World
2. ATAG, WCAG, and UAAG — Accessibility Guidelines
4. Narratives On Accessibility
Most people interact with computers and the internet to display content in an easily digestible format. This is accomplished with a wide variety of web technologies and programs that enable our access to the web. We don’t have to deal with giving the computer instructions via code or working in databases when surfing or buying products online. Web developers have done the hard work to provide us with interfaces and applications that are user-friendly abstractions of complex interactions.
Those sorts of abstractions provide accessibility to users. Most users don’t need to know deep computer science or be proficient in multiple programming languages to use computers to work or browse the web. As we know, and should make a habit of knowing, not all users are the same, so designing accessible programs and web applications is critical to serving the entire spectrum of users who could benefit from the internet. There is a lot to dive into on the topic of accessibility, so think of this story as a overview of key accessibility information and where to find it.
Web Accessibility Around The World
W3C
The World Wide Web Consortium (W3C) is an organization that develops international standards for the web and its technologies. They are all about making the web awesome and widely available. For accessibility, W3C partnered with organizations worldwide across industries, governments, and disability research and advocacy groups to develop the Web Accessibility Initiative (WAI).
WAI
The WAI was established in 1997 to improve the accessibility of the web for users. Comprised of volunteers and staff worldwide, The WAI worked to develop and approve accessibility standards, as well as provide open access to resources and education on web accessibility. The WAI website lists several examples of the components that work together to describe web accessibility:
- Content — the information on a web page or web application, including natural information such as text, images, and sounds
- Code or markup that defines the structure, presentation, etc.
- Web browsers, media players, and other “user agents”
- In some cases, assistive technology — screen readers, alternative keyboards, switches, scanning software, etc.
- Users’ knowledge, experiences, and in some cases, adaptive strategies using the web
- Developers — designers, coders, authors, etc., including developers with disabilities and users who contribute content
- Authoring Tools — software or applications that create websites or web content.
- Evaluation Tools — web accessibility evaluation tools, HTML validators, CSS validators, etc.
Developers use user authoring and evaluation software to create content for the web. Users use their experience with the web and various assistive technologies to consume or use that content.
The W3C/WAI groups the components into three categories of guidelines to develop web accessibility standards:
- Authoring Tool Accessibility (ATAG)
- Web Content Accessibility (WCAG)
- User Agent Accessibility (UAAG)
ATAG, WCAG, and UAAG — Accessibility Guidelines
Each of these guidelines could have entire articles written about them individually. Here is a summary of what they cover.
Authoring Tool Accessibility (ATAG)
The Authoring Tool Accessibility Guidelines are primarily for developers who develop and maintain software that creates or generates websites or web content.
The guidelines cover two main parts: making your authoring tool’s interface accessible and supporting accessible content production. Both are important, but it's worth noting that authoring tools that support and encourage accessible web content, then it is easier for authors(users/developers) to implement those designs. Essentially, if it’s easy for users of the tools to make what they produce accessible, they will do so more often.
Web Content Accessibility (WCAG)
The Web Content Accessibility Guidelines are for web developers, web authoring tool developers, and users who would like a standard for building accessible web content. Adhering to these guidelines require that your web content is:
- Perceivable — Can a user see and hear your content? Can a user use alternatives for non-text content? Can your content be delivered in different ways, compatible with different assistive technologies?
- Operable — Can a user interact with your content with the keyboard? Do you give users enough time to interact with your content? Can a user use input devices other than a keyboard? How easy is your site to navigate? Do you have any content that may cause seizures?
- Understandable — Is your content readable and understandable? Does the content appear predictably? How can you help a user avoid input mistakes?
- Robust — How future proof is your content in terms of accessibility?
User Agent Accessibility (UAAG)
The User-Agent Accessibility Guidelines refer to the accessibility of user-facing software and applications that render web content (browsers, browsers extensions, etc.) This is especially targeting the accessibility of the user agent interface. The guidelines cover many of the same things from the previous two categories but especially deals with accessibility options that the user agent provides that are separate from the web content itself.
Modern Web Accessibility
WAI-ARIA
ARIA stands for Accessible Rich Internet Application. WAI-ARIA is a standard that outlines methods and provides tools so developers can make web applications that use recent web technologies more accessible.
This applies to web applications that use AJAX requests, JavaScript, HTML, and similar technologies to update information on a page based on user interactions. Examples include pages that render content with sliders, dropdowns, modals, and navigable menus. JavaScript UI Libraries like React, Vue, and Angular often fall into the category of Rich Internet Applications.
Some common situations with Rich Internet Applications that can impact accessibility are regions of a web page that change in real-time or in response to a user’s input. Screen readers require solutions to read this content, like content from modals, that may change or disappear.
ARIA is a part of HTML5, which introduced new HTML standards for writing semantic accessible HTML documents. Tags like <section>, <article>, <nav> etc. were introduced to define regions of webpages with a little extra meaning, which cut down on screen readers needing to parse through extensive trees of<div> tags.
Overall, ARIA pro ides roles and properties to better describe web elements to assistive devices and technologies. These roles may describe a menu's behavior or specify a region of content and the actions a user can take in that region. Skip links and hidden navigation, so users don’t have to press tab to find their way around, and adding support for more types of assistive devices and technologies.
Narratives On Accessibility
User Stories
To understand how important it is to consider accessibility in design, it’s useful to consider some narratives that are perhaps outside of our own. I included an example narrative from the W3C/WAI website and links to more at the bottom.
Kaseem is a teenager who is deaf and recently became legally blind too, which means she can see only small portions of a screen and read text when it is significantly enlarged.
Kaseem uses:
screen magnification software to enlarge the text on websites to a suitable font size;
screen reader software that displays text on a refreshable Braille device;
large computer screen with high resolution and high luminosity (brightness).
Kaseem’s portable electronic Braille notetaker includes a calendar, e-mail, web browsing, and note-taking functionality. Her mobile device includes GPS which helps her orient herself and navigate around the city. Kaseem uses the public transportation online site to plan her trips and view bus schedules, but encounters problems when she enlarges the text and it does not reflow or wrap properly, making the maps very difficult to use. She has a better experience viewing the train schedules that are properly marked up and allow text reflow. Kaseem found the web team contact information listed at the public transportation website and sent a message to the team informing them of the problems she encountered using their site. She also sent them the link to the train website and described how that site works better for her. She recently received an email message thanking her for her information and informing her that the public transportation web team plans to implement accessibility improvements in the launch of their new website.
