Web Accessibility: A Primer
Web accessibility has become a legal hot topic, but it’s also integral to creating a useful and usable web presence. This primer is designed to help you get a high-level view of what web accessibility is, how it affects your customers, and a little bit about what can be done to make sure our sites are accessible for everyone.
Web accessibility. A legal hot topic — one that has been at the heart of web design for decades — that has caught fire over the past several years.
The question is often posed in an air of black and white. Can you be sued? What should we do to fix it? Are we accessible or not? The truth is, web accessibility — while backed by legal precedence and defined by a couple sets of rules and guidelines — still continues to float in a bit of a grey area.
Yes: you can be sued for accessibility issues. Just as those who own or manage a physical storefront might be at risk if their building is not made accessible to those with physical disabilities, a website owner can be at risk for not providing reasonable access to web content.
No: the rules are not well defined enough to provide black or white answers to several accessibility standards. There’s no single tool you can use to fix things. It’s not as easy as closing a few tags or making some HTML tweaks. It requires critical thinking and decision making.
When it comes down to it, accessibility is more than just a legal necessity: it’s also at the heart of what we call “web usability.” While there is a definite requirement at a legal level, there’s also a requirement at a practical level to keep within the spirit of web usability in order to provide clear and correct information in a way that’s accessible by everyone.
This post outlines how Blend looks at confirming web accessibility standards on all new sites — as both a legal necessity and as a dedication to the spirit of how we build websites.
On the web, accessibility is the practice of removing barriers for people with disabilities. Much like new building construction must provide accessible entrances, and businesses must provide reasonable accommodations to employees with disabilities, websites must be created in a way that allows access to information despite any existing or future disability.
Who is affected?
Non-accessible websites can affect any number of audiences. Because most websites rely on written and visual communication, the audience most affected by accessibility issues are those with temporary or permanent vision issues. If you cannot see a website, it’s clearly very difficult to parse information from that website.
But, of course, it’s more complicated than that. It also affects those who have motor or mobility disabilities — such as those with cerebral palsy, or someone who has recently had a stroke. It affects those with auditory disabilities, such as deafness. It even encompasses those who have cognitive disabilities or language barriers.
And, as mentioned earlier, accessibility issues aren’t always black or white. Someone who is hard of hearing requires just as much accessibility thought as someone who is completely deaf. It’s also not always permanent — a broken hand, a loss of vision due to eye dilation, or even an ear infection can hamper the use of a website, and all should be handled accordingly.
Why does it matter?
These things aren’t decided in a vacuum, from site to site — they are required by law. The Section 508 Amendment to the Rehabilitation Act of 1973 requires all sites to be accessible, and requirements are further spelled out in the Web Content Accessibility Guidelines (WCAG).
And, they’re very real — ask Winn-Dixie, who was at the heart of a Federal Court ruling that an inaccessible website violates the American Disabilities Act.
But it’s not all about lawsuits.
On one hand, it’s about building a solid, useful website filled with easy to parse content. Adhering to accessibility standards helps with search engine optimization, helps make sites easier to navigate for people on mobile devices, and, by nature of reaching more people, faster and more clearly, actually increases sales and impressions.
It’s about being inclusive. It’s about making the web a better place for everyone; for making it accessible not only for those who have a legal need, but also for those who have a temporary need, or those who simply feel more comfortable with certain settings.
What should you look for?
While this feels like an innocuous enough question, the truth is that accessibility is both well defined and, at times, a bit vague. So the answer is often “it depends.”
There are different guidelines for accessibility. The World Wide Web Consortium (W3C) has developed a set of Web Content Accessibility Guidelines that follow four principles; decisions around web accessibility should be user-centric, and deal with making a website:
What level you decide to perform may depend on your situation — your industry, your audiences, and your visibility and likelihood to be used as an example. Additionally, Section 508 guidelines — as required by the Rehabilitation Act of 1973 — provide a different set of touchpoints from which to test accessibility.
Ultimately, though, the decision should come down to two things:
- How much inclusivity can we provide within our existing workflow (HINT: that answer should always be “as much as possible”)
- How much will a lack of inclusivity harm or exclude users with permanent or temporary disabilities?
Accessibility for vision.
Vision disabilities cause the bulk of accessibility concerns. As mentioned above, the web is largely still a visual medium. It relies heavily on an expected level of vision. But not all vision disabilities are related to something large, like blindness. Vision disabilities also include:
- Low vision, caused by things such as cataracts, glaucoma, or macular degeneration
- Temporary blindness or low vision
- Color blindness
Accessibility for vision includes the following:
- Sizing — Where web design once tied closely with print design — every font meticulously chosen, every pixel in its right place — the past decade has rightfully shifted toward a fluid adjustment based on content needs. For example, modern designers often use more scalable font measurements, which allow low-vision users to adjust the fonts larger for better readability.
- Contrast and color — Those with low vision often have difficulty differentiating between similar colors, which makes the practice of putting red text on a black background more than just an eyesore — it’s 100% inaccessible. Additionally, poor color patterns and contrast issues affect those with color blindness.
- Handling non-text content — If you can’t see an image, you can’t know what it says. From alternative text that explains the image to straight up ignoring images that do not provide context or value to the page, non-text content is one of the biggest (if not the biggest) accessibility issues.
Accessibility for motor.
Motor issues can be temporary — like a broken arm — or they can affect every part of everyday life, such as someone who suffers from a neurological condition. While those with motor disabilities may be able to view and understand the content on the screen as is, they may not be able to interact with content, which may impede their ability to follow through on forms or access deeper content.
Accessibility for motor includes the following:
- Keyboard accessibility — Not everyone is able to navigate a mouse (or see where the mouse is pointing) — and, more often than ever, not everyone wants to use a mouse. Every link, button, and access point on a page should be accessible via the keyboard alone, and the current focus of the page should be highlighted in a way that’s easy to see.
- Element sizes — Too-small buttons and small margins of error can really wreak havoc on someone with motor disabilities, especially if they are not steady with their mouse or interactive device. What’s more, too-small buttons become an issue for those without motor disabilities when it comes to smaller screens such as mobile phones.
- Error tolerance — If a user selects an unsupported or incorrect option, how long do they have before they’re locked out? If one interaction leads to another, such as clicking a button to open up a list of options, how long will that second interaction take, or will it disappear before the user is able to reach it?
Accessibility for auditory.
Because accessibility standards and fixes so often focus on visual and motor interaction with a website, we often overlook those who cannot hear — either because of a permanent hearing disability or because of temporary or contextual hearing loss, such as plugged ears or a loud workplace. This most often manifests with videos, but other aspects of the web also play into the hearing impaired.
Accessibility for auditory includes the following:
- Captioning on videos — Video captioning can be done either manually or automatically, depending on the content source (YouTube provides a wonderful first stab at captions, if you don’t mind cleaning up common nouns and other misspellings).
- Captioning on podcasts — Of course, if you can’t hear a video, you also can’t hear any other kind of audio media, such as podcasts. Providing transcripts of podcasts or audio-only content not only gives those who can’t hear access to your content, but it also provides more search terms and keywords.
Accessibility for cognitive.
Finally, a site user may be able to see, hear, and interact with the content — but are they able to comprehend it? Cognitive accessibility focuses on understanding the content on the page itself, from whether or not it’s simple enough for the audience to understand to staying away from idioms and other language quirks that are troublesome for language translators.
And while most laws and regulations don’t require cognitive accessibility except at the highest levels of compliance, certain industries and verticals — especially government and public service sites — may find cognitive accessibility the most important way to be inclusive.
Accessibility for cognitive includes the following:
- Speed and decision time — Forms and interactive content need to be presented in a way that don’t fly by too fast — no inaccessible time limits on entering form content, no fast scrolling instructions, and definitely no “flash on the screen, then disappear” modals.
- Writing style — Using jargon, rambling sentences, or high-level vocabulary words when there are simpler terms available isn’t just bad writing — it’s bad for accessibility. Using plain and clear language helps those with cognitive disabilities, but it also helps those who speak English as a second language or are using translators.
- Consistency — Along with using plain language, writing consistently is incredibly important in helping people understand your content. Don’t name your form or process one thing, and then switch the name of it on another.
The accessibility process.
Accessibility — even more than the content itself — is often the single unifying piece of a web project, from initial content strategy and design to migration and site launch. In this way, we don’t have a formal “accessibility” practice or process — instead, building accessible sites is a part of every project we create.
From the outside, accessibility looks like a design issue, and that view isn’t wrong. Designing a site in a way that’s viewable and consumable for those who can’t view or consume content in the traditional way requires more than just bigger font. It means allowing users to navigate the site — in a logical order — using keyboards or assistive devices. It means making sure design isn’t a detriment to the site, and instead confirming its usefulness to both those with disabilities and those without.
This also lands on the content design team, who suss out accessibility issues during the content strategy process. Through site planning and wireframes, the content team helps the design team understand the function of where content will live and how it will be organized — important knowledge that helps facilitate a logical site structure, heading levels, navigation patterns, and site functionality.
(What do we mean by a logical site structure? We mean organizing headings in the same way that your research paper were organized in high school — main points, supporting arguments, and proper heading levels that a screen reader can understand. We mean using descriptive links that say exactly where the user will go, instead of “Click Here!” or “Read More!” We mean uncovering elements of the page in the order they are to be read, not in a random order dictated by location or which point they were added in the development process.)
There are a lot of areas where web design and content have evolved past print, and accessibility is at the heart of much of it. Which is why it’s so important to find a web design firm — or hire web designers for your internal staff — that can be confident in their design choices and provide a bit of pushback to old, non-accessible design standards. While web design can still push boundaries, becoming more than just boxes on a grid, there needs to be a balance between edgy and usable. There needs to be someone who can stand up when the carousels and weird fonts are broken out, and take up the charge on the side of web accessibility.
Of course, all of the accessibility allowances mean nothing if they aren’t integrated into code. At Blend, most accessible design elements are implemented by the designers themselves as they construct their front-end code. However, the back-end developers serve as a second wave of checks, confirming that the content management system understands heading levels, allows for editor overrides, and (ultimately) provides the rules that help govern accessibility after the site has launched.
Beyond the design, development helps ensure that functionality follows the correct outline, regardless of what’s been bid for functionality. For example, development builds a “skip to content” link into every one of our sites, because we know that someone using a screen reader does not want to get through the entire navigation before reading the page content. Most development-side accessibility functions are not options — they are part of what we do to build a site, and therefore are non-negotiable.
Content will define the function of the site, and design will create the blueprint for which accessibility is to follow, but the development process ensures that both are implemented in a way that actually helps a site user.
After the site has launched.
And then there’s the content itself.
While much of the content work is handled on a structural level during content and visual design, there’s still the act of writing, posting, and maintaining content — the words and pictures, the labels and titles.
An accessible design and content management system aren’t going to help if content is thrown on the site without any thought to how it’s structured. Which means despite accessibility work being facilitated through design and development, it ultimately relies on the ongoing editorial power of a site’s content team.
This is the point in which we see most accessibility fail — not because it was built incorrectly, but because control is moved from a team of web design and development experts to day-to-day editors who already have a ton of things on their plate. They have a massive amount of content to upload, and they get it up as fast as they can before moving on to the next step.
The design or content management system may understand the structure in which content is entered, but it will never understand the context — both are, at their base, robots, unable to understand the syntax of written language. It’s up to us as humans to make our content work for humans who cannot see or hear it. It’s up to us to make sure we caption our videos accurately, and we provide usable alternative text for images, and we structure our articles using a standard heading style, and it’s up to us to make sure we train our editors to understand why accessibility is important.
Cool! That seems easy.
Nah. It’s not easy. It’s never easy.
There’s a grey area in content accessibility, because the rules are not black and white — and neither are the testing tools or screen readers we employ to help us. There are times when we need to go against an “expected” accessibility fix because, simply, it is the opposite of what we actually intend.
For example, the rule for non-text elements (such as images) is that they should provide some kind of text equivalent, so that someone using a screen reader can access the same breadth of content that an able-visioned person can. However, not all non-text images are worth talking about. If you are looking at a faculty directory on a university site, the image next to the person’s name is completely worthless to a screen reader — you’ve already read that person’s name, and assigning alternative text to the image will just cause the screen reader to read that name again..
This means the decision to create alternate text for an image is done on a case-by-case basis. Editors cannot blanket all images with long descriptions, as these can actually clutter and disorient the content a screen reader encounters. Instead, the decision to provide an alt tag — or to determine the correct headings, or to manage form fields, or even to decide whether to use an idiom or metaphor — is 100% dependent upon the context and use of the page.
Miss an alternative text tag? Some testing tools might flag you as being non-compliant. So the question is: do you work for the test? Or do you work for the user?
How can I check?
There are a lot of tools out there, some of which are better than others. Keep in mind: tools will show you where your problems may lie, but few — if any — will actually provide any real solutions, as mentioned above.
Given that so many accessibility issues land in the court of the development team (changes to CSS, changes to site structure, changes to content metadata systems) or in the court of your editors (mass updates to alt tags, heading style, and content style in general), putting together an action plan for accessibility updates is a real project that requires real time and real attention.
In fact, when we provide accessibility audits to clients for their older sites, they also come with a list of potential changes, updates to editorial workflow, and a budget for making things right. Accessibility issues aren’t things you fix overnight — they are deep in the very structure of the site, which is why most web agencies are so serious about accessibility work.
With that in mind, here are some of the tools that we use at Blend to help suss out accessibility issues within our projects.
- JAWS — We use JAWS to test in most cases, but with the downside that it’s not a Mac screen reader. If you’re looking for something on a Mac, you’re always free to try the Mac Voice Over app by selecting CMD+F5.
A lot of the testing we do is using browser extensions.
- WAVE — WAVE is the market leader, it seems, helping identify code-level and content-level accessibility issues as well as contrast issues. It’s available for both Chrome and Firefox.
- Contrast Checker — WebAIM’s color contrast checker is also great for testing color values. This is the one we send to clients, and they’ve found it helpful.
Understanding the landscape.
The following sites are integral in getting both a high-level understanding of web accessibility and also keeping up with the changing landscape of regulations.