The A11Y Project

Accessibility is 'blind people'

2013-01-11T00:00:00Z

Accessibility is often viewed as making your site work on screen readers. In reality, web accessibility is a subset of User Experience (UX) focused on making your websites usable by the widest range of people possible, including those who have disabilities.

Four categories of accessibility

Accessibility can be broken down into four key categories:

Visual

This can be non-sighted users, users with low-vision, users with obstructed vision, or even simply your aging parents.

Associated conditions

Myopia
Colour blindness
Glaucoma
Albinism

Auditory

The web is a visual medium, but captions and fallbacks for sound-necessary media need to be considered for hearing impaired users.

Associated conditions

Presbycusis
Acoustic trauma
Auditory processing disorder
Otosclerosis

Motor

People with motor impairments typically use a wide range of assistive technology from specialized keyboards, to eye trackers, to using single buttons (a device known as a "switch") to navigate their computers.

Associated conditions

RSI
Cerebral palsy
Parkinson's
Muscular dystrophy

Cognitive

Relates to the ease processing of information.

Associated conditions

Down’s syndrome
Autism
Global developmental delay
Dyslexia

Temporary disabilities

While each of these disabilities is usually permanent, there are often situations in which even fully-abled people are "temporarily disabled". For instance, an arm or wrist injury may temporarily prevent you from being able to use a mouse.

Robin Christopherson (an accessibility expert who is blind) once spoke about how people that are driving but use hands-free sets or have their phone connected to the car radio are temporarily disabled, as they use the phone differently to how they normally would. Of course, no one should browse websites while they are driving but it is important to understand different situations like that, where the user may not have special software installed that a disabled user might.

Navigate using just your keyboard

2013-01-11T00:00:00Z

Testing your site for keyboard navigation will help ensure that keyboard users can access your site.

As a bonus, sites that can be navigated with a keyboard are more likely to be navigable with other input devices such as switches.

How to navigate a website with a keyboard

Generally, pressing Tab moves focus between interactive elements and pressing Enter will interact with them.

If you are using Safari, Option + Tab is the default keyboard shortcut to move focus between elements. You can update your settings to make Tab the default navigation key by following the instructions in this article: Quick Tip: Safari Keyboard Navigation

Additional keyboard shortcuts are described here: WebAIM - Keyboard Accessibility

Things to keep in mind while testing

It is not enough to simply tab through a webpage from start to end. While navigating the site, keep these things in mind:

Interactive elements should be functional using only keyboard input.
The focused element should be visible and have an obvious focus style. See article: "Quick Tip: Never remove CSS outlines".
Focus should move between elements as they appear on the page and not jump back and forth.
There should be a way to skip past lengthy spans of content, like global navigation menus. See article: "How–to: Use Skip Navigation links".

Using alt text properly

2013-01-14T00:00:00Z

The alt attribute is meant to provide "alternate text" descriptions of images to help ensure people do not miss out on information conveyed by graphics.

Alternative text can help people using assistive technology, such as screen readers, or people who have images turned off on their mobile devices (to save data, for instance). Additionally, alt text can be useful to everyone in instances of poor Internet service, or your CDN of choice having a service hiccup (or attack), and images are slow or fail to load.

A few tips on how and when to use the `alt` attribute:

Use the alt attribute for images that are used as more than decoration. The alternative text describes the primary purpose of an image and is rarely a detailed description of the image itself (unless, for example, the page is actually about a specific image).
Make sure the description of the image is useful. For example, if the image is of a company's logo, the alt should be the company's name. The word "logo" is not necessary or useful as part of the alternative text.
Don't begin alternative text with "photo of..." or "picture of...". Assistive technologies already indicate the role of the element as an "image" or "graphic". Redundancy makes for poor user experiences.
Don't put line breaks in alt text. Doing so can cause awkward screen reader announcements. For instance, inserting the element's role "graphic" and unintended pauses prior to each line break.
Use an empty alt attribute for any image that is decorative or not necessary for understanding the content of the page. For example, an image providing decoration to an article's heading could be hidden by giving the image an alt="" or simply alt
Using an image several times in a website doesn't necessarily mean the alt attribute will be the same for each instance. For example, a logo within a website's header often doubles a link back to the home page. In this example, the alt would be useful as "Company's name - home". If that same logo were used in the footer of the site, next to the text "Company's name, copyright 20XX", then the logo would have an empty alt (alt="") so as to not create a redundant announcement of the company's name.
There may be other times where images are used within links, but are decorative to the visible label of the link. For example, if the image is an icon of a phone and part of a "contact" link, the alt could be empty as the text of the link indicates what the icon represents.

ARIA Landmark roles and HTML5 implicit mapping

2013-01-14T00:00:00Z

ARIA Landmark Roles can be helpful to assistive device users, as they can be used to orient a user to, and easily navigate, your website or application. For a quick video demonstration, check out "How ARIA landmark roles help screen reader users", by Léonie Watson.

Landmark quick reference

The following are common landmark roles that tend to be useful on many pages:

Typically the primary “header” of your page, containing the name of the site/application along with other globally available content. It MUST be scoped to the body element, and not within another sectioning element, or the main of the document.

search

Use on the primary search form. Often, but not always, found within a banner. If you have multiple search landmarks in a document it would be good to provide them with unique accessible names to indicate how they differ.

main

Designates the primary content area of the current document. Only one main landmark should be exposed to users at a time.

Used to promote an area as a navigation. Combine with a unique aria-label to provide context of the navigation's purpose. e.g. <nav aria-label="primary">.

contentinfo

Typically the "footer" of your page that contains information about the parent document such as copyrights and links to privacy statements.

Implementing landmarks in your documents is a straightforward process. Simply add the role attribute referencing the appropriate landmark value. For example:

<div role="contentinfo">
  ...
</div>

HTML5 implicit mappings of Landmark roles

Before you start adding ARIA roles to your HTML elements, you should be aware that many of these landmarks will be natively conveyed by proper HTML usage. For example, the following markup snippet will produce a warning in modern HTML and accessibility automated checkers:

<header role="banner" class="site-header">
  ...
</header>

The following table outlines the different ARIA landmarks, and the HTML5 element they are associated with:

Landmark Role	HTML Element
banner	`<header>` (if not a child of a sectioning element or the `main`.)
complementary	`<aside>`
contentinfo	`<footer>` (if not a child of a sectioning element or the `main`.)
form	`<form>` (if provided an accessible name via `aria-label` or `aria-labelledby`)
main	`<main>` (only use one per page)
navigation	`<nav>`
region	`<section>` (if provided an accessible name via `aria-label` or `aria-labelledby`)
search	none

The majority of modern browsers (except Internet Explorer) support these mappings. But it's always beneficial to run your own tests to ensure the appropriate landmark role is being appropriately exposed to assistive technology.

For example, there are still support gaps in browsers and screen readers for exposing some landmarks. When presented with situations like this, ignoring conformance warnings, and adding a redundant role to an element, may be preferred to not exposing the correct landmark information.

Getting started with macOS VoiceOver

2013-01-14T00:00:00Z

VoiceOver is the assistive software built into macOS. It provides a richer set of keyboard shortcuts for navigating a website and reads sections of the page aloud based on the current focus. It’s a great way to test the accessibility of a project because it’s always readily at-hand: you can toggle VoiceOver on/off by:

Toggling it to “on” under “Universal Access” in your system preferences.
Pressing Command + F5

Turning on VoiceOver enables a number of navigational key commands, all of which are performed by pressing Control and Option. This is usually abbreviated to “VO” in Apple’s documentation (so VO + F1 means Control + Option + F1).

To start out, try turning on VoiceOver with Command + F5, then use VO + F8 to open VoiceOver’s preferences window—here you can adjust things like the voice used, speaking speed, and under “web”: your navigation method.

There are two modes you can use when navigating with VoiceOver: by “grouping items” or by “DOM order.” These two methods allow you to interact with a page’s content in slightly different ways.

Grouping items

Grouping items will flag that you are currently focused on a list, and you can begin interacting with the items by pressing the down arrow to “drill down” into those items. This mode attempts to group related content based on how the page is being rendered, and navigating by group will allow you to use the arrow keys to move in any direction. We’ll be focusing on this mode.

DOM Order

DOM Order will flag that you are entering a list of items, and drill down into those items automatically. This mode is based entirely on the page’s underlying markup. Navigating by DOM order allows you to shift focus between DOM elements with the left and right arrow keys. The up and down arrow keys are based on the last used navigation method in the “Web Item Rotor.”

Reading text

Here are some basic interaction and navigation commands for VoiceOver.

Command	Description
`VO` + `Shift` + `Down arrow`	Interact with an item
`VO` + `Shift` + `Up arrow`	Stop interacting with an item
`VO` + `Spacebar`	Perform the default action for the item in the VoiceOver cursor
`VO` + `R`	Read a row in a table
`VO` + `C` + `C`	Read a column in a table
`VO` + `Up arrow`	Move up
`VO` + `Down arrow`	Move down
`VO` + `Left arrow`	Move to previous
`VO` + `Right arrow`	Move to next

The Web Item rotor

VoiceOver's Web Item Rotor.

Open the rotor by pressing VO + U with VoiceOver enabled, and you’ll be presented with a list of navigational elements on the current page. You can use the rotor to jump directly to links, headings, form controls, tables, web spaces, and ARIA landmarks. You can switch between these navigation methods using the left and right arrow keys, navigate through the list using the up and down arrow keys, and select an item using the enter key or the spacebar.

You can start getting a feel for VoiceOver right here on a11yproject.com. Try it out!

Never use `maximum-scale='1.0'`

2013-01-14T00:00:00Z

Using the viewport meta tag the wrong way can prevent people with low vision concerns from accessing your website or web app.

About the `maximum-scale` attribute

By setting maximum-scale=1.0, you are disabling the functionality to use pinch zoom on certain mobile devices, forcing people to view your page a certain way.

The bad way

<meta
  name="viewport"
  content="width=device-width, initial-scale=1.0, maximum-scale=1.0">

The good way

<meta
  name="viewport"
  content="width=device-width, initial-scale=1.0">

Avoiding maximum-scale="1.0" allows your site to meet users' needs and provide a better experience.

In iOS 10, Apple changed its handling of user-scalable, min-scale, and max-scale declarations. Their changes removed the effect on pinch-zooming, making it possible to pinch-zoom regardless of the meta element's suggestions.

However, other effects of the declarations remain, like their effect on whether the browser automatically zooms into focused input elements. And other mobile browsers, including Chrome on Android, still forbid user zooming when a maximum-scale="1.0" rule is present.

About the `user-scalable` attribute

The user-scalable attribute can also cause problems for people who use the built-in zoom functionality of their web browser.

The attribute is set as user-scalable="yes" by default, which means that people are able to control the zoom setting for the page they're visiting. Changing it to user-scalable="no" would prevent zoom settings from working on both mobile and desktop devices.

Avoid setting user-scalable to no to assure better accessibility of your site. Either leave it as default by not referencing the user-scalable attribute, or set it to yes.

Don't auto-play video, music and more

2013-01-15T00:00:00Z

Not auto-playing your media will make everyone happy.

Sound

People using screen-readers navigate by listening, so any sound playing when the page loads will interfere immensely. It will also be frustrating to any person that may be listening to music or is in a quiet area with their sound on high.

In a note on audio control, the Web Content Accessibility Guidelines (WCAG) suggests:

Therefore, we discourage the practice of automatically starting sounds (especially if they last more than 3 seconds), and encourage that the sound be started by an action initiated by the user after they reach the page, rather than requiring that the sound be stopped by an action of the user after they land on the page.

Vision

Vision includes video and CSS/JavaScript animations like slide-shows and carousels.

Some groups of people may have a problem with moving content on a web page that starts without warning. This includes people with certain types of learning difficulties who can find it hard to concentrate or focus on tasks when distractions are present.

In HTML5

The HTML5 specification includes the autoplay attribute along with the following provisions:

Authors are urged to use the autoplay attribute rather than using script to trigger automatic playback, as this allows the user to override the automatic playback when it is not desired, e.g. when using a screen reader.

Even though an autoplay attribute is included they also suggest:

Authors are also encouraged to consider not using the automatic playback behavior at all, and instead to let the user agent wait for the user to start playback explicitly.

What if you can't say no?

As web developers, we don't always have the luxury of making business decisions, so there are a couple of recommendations to follow:

Ensure media lasts for five seconds or fewer before stopping for good.
If media lasts over five seconds, you must provide the user with an option to stop or pause it.

It is also considered good practice to indicate a link will navigate to a location that contains auto-playing media. For example, a link to YouTube could be written as, "Beethoven - Moonlight Sonata (YouTube)".

Check contrast with your mobile device

2013-01-22T00:00:00Z

Having good contrast and readability are an important part of creating an accessible website.

One trick you can do to test whether or not your contrast is sufficient enough is by using your phone or mobile device.

Set the brightness of your mobile device to its lowest setting.
Open up your website on the device and begin browsing around.
Optionally, try viewing your site in direct sunlight.

If you find something difficult to read, you may have found an accessibility issue! Take measures to check and increase the contrast of your text.

Available tools

Future-proofing your accessibility efforts

2013-01-22T00:00:00Z

Your future self, coworkers, and most importantly customers and clients will thank you for developing with accessibility in mind.

Tech debt goes down when accessibility goes up

The best way to future proof your accessibility efforts is to ensure websites and applications are built with a foundation in proper HTML semantics. We can help ensure we are future-proofing our project by following two rules from Web Content Accessibility Guidelines (WCAG): Parsing and Name, Role, Value.

Following these rules has the bonus value of better supporting current and future browsers and other user agents, while additionally ensuring assistive technologies (AT) such as screen readers will be more likely to correctly interpret the content of our projects.

Breaking down the rules

Let's define the WCAG rules and look at some quick tips to help follow them.

4.1.1 Parsing

Following this rule helps ensure that browsers and AT will be able to correctly interpret your web interface without complications from poorly-structured markup.

The W3C Nu HTML Checker can help you locate errors in your source or rendered markup. Any reported validation can be corrected, which will help decrease the likelihood of ATs incorrectly parsing your website.
Follow the official HTML specifications for guidance on writing correct markup. Some quick tips: make sure to close open tags (<div class="a-class">...</div>), use unique ids, and don't incorrectly nest HTML elements.

4.1.2 Name, role, value

This rule is related to the components and controls that make up the web interface. It helps to ensure components can have their name and role programmatically determined, and that their states, properties, and values can be set by the individual interacting with them.

All standard HTML controls already meet these rules by default. The guideline is primarily aimed at developers that heavily redesign or modify the functionality of standard HTML controls, or design and/or script their own interface components and controls from scratch.

Wrapping up

While these are only two of the criteria to follow to make your website more accessible, they should take a prominent spot in every web developer's workflow.

Additionally, the use of checklists, such as The A11y Project checklist, can help you future-proof your accessibility efforts.

A primer to visual impairment

2013-01-22T00:00:00Z

Visual impairment is a condition that limits the visual capability of an individual to such a degree that additional support is needed.

It is the result of trauma, disease, congenital, or degenerative conditions that cannot be corrected by medication, surgery or refractive correction. 90% of the world's visually impaired live in developing countries and 80% of all visual impairment can be avoided or cured by conventional means.

According to the National Federation for the Blind, 7,297,100 people over the age of 16 were reported to have some level of visual impairment, as of a 2015 American Community Survey interpreted by Cornell University's Employment and Disability Institute (EDI).

There are 3 levels of visual impairment:

Moderate visual impairment
Severe visual impairment
Blindness

According to The United States Bureau of the Census:

The question about “significant vision loss” encompasses both total or near-total blindness and “trouble seeing, even > when wearing glasses or contact lenses.” and [...] There are no generally accepted definitions for “visually impaired,” “low > vision,” or “vision loss.”

Statistical Facts about Blindness in the United States - National Federation of the Blind

Who is at risk?

65% of visually impaired people are over 50 years old. With an ever increasing elderly population in many countries, more people will be at risk of age-related visual impairment.

An estimated 19,000,000 children under 15 years are visually impaired with 12,000,000 due to refractive errors that have not yet been diagnosed or corrected, while 1,400,000 are irreversibly blind.

The causes

Disorders of the eye that lead to visual impairments can include:

Refractive errors (myopia, hyperopia or astigmatism) are typically the result of nature with 43% of visually impaired born with refractive errors that can be corrected with medication, surgery, glasses or contact lenses.

The challenges

Equality is the most important challenge that faces those with visual impairments. However, thanks to improved assistive technology, braille, and other specialized tools, the rest of the world is beginning to understand that the visually impaired population are capable of the same things as those with near-perfect vision.

A greater dependence on what we might take for granted is also very important. Electricity is a huge factor when it comes to content. Without it, a person who relies solely on a screen reader cannot simply browse a book, magazine or newspaper. This, in turn, puts greater demand on media that originated in print to be made available through computers where screen readers can assist.

The future is bright

Louis Braille invented the Braille system for reading and writing in 1824, giving access to previously inaccessible literature. Helen Keller overcame the institutionalized education system of the 19th century, becoming the first deafblind person to earn a Bachelor of Arts Degree. Bob Stepp developed the first Braille editing program in 1980, and in the modern era we hold the key to accessibility for this generation and many more to come.

The challenges of yesterday are the opportunities of today.

Check comprehension level

2013-01-25T00:00:00Z

People with cognitive disabilities often struggle with reading text on the Internet. When writing content, it is important to identify your target audience and write accordingly.

If you don't know who your audience is, target your content towards a reader between the ages of 12 and 15 years old.

Here are some tools to test your content:

If your content isn't hitting the target audience, take some time and rewrite it.

Never remove CSS outlines

2013-01-25T00:00:00Z

Removing outlines in CSS creates issues for people navigating the web with a keyboard.

Using the CSS rule :focus { outline: none; } to remove an outline on an object causes the link or control to be focusable, but removes any visible indication of focus for keyboard users. Methods to remove it such as onfocus="blur()" result in keyboard users being unable to interact with the link or control.

If you do not like the default focus outline that is displayed when a user clicks on an interactive element, you have 3 accessible solutions:

Style the outline. Webkit browsers have a more prominent glow so you could try styling it to make it less obtrusive. Consider the use of a:focus { outline: thin dotted; } to normalize the look of the outline across browsers.
Style the element itself. You can remove the outline as long as you style the focused element differently (using a combination of color, background-color, border or text-decoration: underline for example). When using this approach, avoid using color alone as the only visual means of determining focus, as colorblind people may not be able to distinguish the focus state from the inactive state.
Remove outlines for mouse users only, if you truly must do so. Start without applying any outline: none rules. If a mouse event is detected apply those rules using JavaScript. Remove the rules again if keyboard interaction is detected. Here are 2 examples of accessible outline removal scripts:
- outliner.js, a cross-lib implementation with event delegation, by Aireh Glazer
- outline.js, a similar approach that uses mousedown instead of mouseover, by Lindsay Evans
- What Input?, differently from the previous two, adds an attribute to your body allowing you to write CSS that will be enabled only if the user is using the keyboard to navigate.

Consider this third solution as a last resort. Some browser/screen reader combinations fire mouse events, which could cause outlines to disappear while using this method.

In conclusion, using outline: none without proper fallbacks makes your site significantly less accessible to any keyboard only user, not only those with reduced vision. Make sure to always give your interactive elements a visible indication of focus.

Use `role='application'`

2013-02-09T00:00:00Z

Never use role="application" on a widely containing element such as <body> if your page consists mostly of traditional widgets or page elements such as links that the user does not have to interact with in focus mode.

Using role="application" unnecessarily can cause huge headaches for any assistive technology user trying to use your site/application. Only put it on the <body> element if your page consists solely of a widget or set of widgets that all need the focus mode^[1] to be turned on.

Do

Use sparingly.
If your page has no resemblance to a classic document in roughly over 90% of its content.
Use clear labels within your application.

Don't

If a set of controls or user interface only contains these widgets that are all part of standard HTML^[2]
If your widget is dynamic such as a tree view, slider or table.

Unless you take a great deal of care in ensuring that you’ve recreated a lot of native–ish custom navigation, it’s almost always better to let the browser/assistive technology handle things. We only recommend using role='application' on a per–widget basis, and even then: very, very carefully.

Allows the user to interact with forms and ARIA–enabled HTML elements. ↩︎
Standard HTML refers to: text, password, search, tel and other newer input type derivates, textarea, checkbox, button, radio button (usually inside a fieldset/legend element wrapper), select & option(s), links, paragraphs, headings, and other things that are classic/native to documents on the web. ↩︎

Hide content

2013-02-15T00:00:00Z

Developers commonly use display: none to hide content on the page. Unfortunately, this common action can be problematic for people who use screen readers, especially if the hidden content was meant to be for them to discover...

There are real world situations where visually hiding content may be appropriate, while the content should remain available to assistive technologies, such as screen readers. For instance, hiding a search field's label as a common magnifying glass icon is used in its stead.

The "clip pattern" accomplishes this task for you; hide the content visually, yet provide the content to screen readers. Unlike CSS positioning and negative text-indent techniques, the "clip pattern" also works with RTL (Right-to-Left) languages for localization. See the article Hiding Content for Accessibility for more information on this visually-hidden pattern. Also read Beware smushed off-screen accessible text for information on the added line in the code snippet.

.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

If the .visually-hidden class is applied to natively focusable elements (such as a, button, input, etc) they must become visible when they receive keyboard focus. Otherwise, a sighted keyboard user would have to try and figure out where their visible focus indicator had gone to.

With modern browsers and IE9 and up, the visually hidden selector can be written like so:

.visually-hidden:not(:focus):not(:active) {
  /* ... */
}

This will ensure that if an interactive element receives focus, the styles of the .visually-hidden class will be undone and the focusable content will be exposed.

Many popular CSS frameworks provide a .visually-hidden or .sr-only class, where sr stands for "screen readers".

Alternatives to `display: none`

The aria-hidden="true" attribute produces the opposite effect of the .visually-hidden class. It hides content from assistive technology, but not visually. This can be helpful in cases where there are visual cues that screen readers do not need to announce, such as decorative icons that accompany text labels.

There may be instances where content hidden by aria-hidden may also need to be visually hidden as well. Rather than toggling another class on the element, the aria-hidden attribute could be used as the selecor:

.my-component[aria-hidden="true"] {
  display: none;
}

Another way to hide content both visually and from assistive technology is the HTML5 hidden attribute. To support older browsers like IE9, and to increase the specificity of the hidden attribute, you can add the following snippet to your CSS:

[hidden] {
  display: none !important;
}

People who use screen readers don't use JavaScript

2013-04-21T00:00:00Z

A common misconception among web developers is that screen readers only read the non-JavaScript page. Due to this misconception, we sometimes assume it's unnecessary to make JavaScript apps and other functionality accessible. This is categorically false.

According to a January 2014 survey conducted by WebAIM, 97.6% of screen reader users have JavaScript enabled.

Be sure to make efforts to ensure that all functionality (apps, custom UI controls, forms, etc) within your site is accessible with JavaScript enabled as well as provide accessible fallbacks for the 2% of users (globally) with JavaScript disabled. A good starting point might be to use native anchor links and form inputs instead of custom scripted form elements.

Use `title` attributes

2013-04-22T00:00:00Z

Short answer: Don't use them, except in special circumstances.

HTML title attributes are often perceived as an accessibility (and SEO) bonus, but the opposite is true. For screen reader users the content included inside of the title attribute is typically unnecessary, redundant, and possibly not even used. Conversely, content being put in the title attribute is being hidden from the (probable) majority of your users. If information is being hidden from the majority of your users, then it's likely not necessary.

There are a few times when using a title attribute is appropriate:

For <frame> and <iframe> elements
For providing a label when a text label would be redundant

If you must use title on images, keep it the same as the alt.

Based on the intended behavior for Text Alternative Computation the precedence for calculating a text alternative should be:

aria-labelledby
aria-label
alt
title

In cases where two or more of the above are used, whatever is highest in that list becomes what gets used. Consider the following example:

<img src="/path/to/image.png" alt="" title="some stuff that could be useful" />

In this case, the alt actually becomes the alternative, because it is higher in precedence. So even though the title has useful content, it doesn't get used because the alt is there. For a universally reliable text alternative for images, the alt attribute should be the the preferred method. In cases where a title attribute is provided, it should have the same value as the alt.

The long story short? Serve all users equal content.

A primer to vestibular disorders

2013-05-05T00:00:00Z

Your Vestibular system is the sensory mechanism in the inner ear that detects movement of the head and helps to control balance.

Imagine a world where your internal gyroscope is not working properly. Very similar to being intoxicated, things seem to move of their own accord, your feet never quite seem to be stable underneath you, and your senses are moving faster or slower than the rest of your body.

Your personal steady-cam is broken. Whatever you look at tends to move regardless of if you are moving. Let's take that feeling and check out that great new website with animations and parallax scrolling. Does your stomach want to jump out of your throat? Well for many people it does.

What is it?

People with vestibular disorders have a problem with their inner ear. It affects their balance as well as their visual perception of their world around them.

Sometimes the sensation lasts only a short while, but others can experience it for years. Walking can become a challenge and they may experience a constant risk of falling. Concentration can be diminished, leaving a person unfocused and consequently unproductive. It is often viewed as a "hidden" disability because it has no outward showing symptoms.

Who is at risk?

The cause may be from illness, injury, or a genetic condition, but anyone can suffer from a vestibular disorder. According to vestibular.org, a resource for people with vestibular disorders, as many as 35% of adults aged 40 years or older in the United States have experienced some form of vestibular dysfunction.

What should you consider?

Don't make animations, sliders, videos, or rapid movement start automatically. Give an indicator of what movement will happen on the site when someone takes action. Allow the option to turn off any animation and movement at any point in the process.

Also, with the CSS prefers-reduced-motion media query you can write conditional CSS animations and transitions based on the user's preference exposed from the browser settings. For example, you can disable all animations and transitions for users who explicitly prefers reduced motion:

img {
  animation: slidein 3s;
}

@keyframes slidein {
  from {
    margin-left: 100%;
  }

  to {
    margin-left: 0%;
  }
}

button {
  transition: transform 1s;
}

button:focus,
button:hover {
  transform: rotate(360deg);
}

@media (prefers-reduced-motion: reduce) {
  *,
  ::before,
  ::after {
    animation-duration: 0.001s !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.001s !important;
  }
}

Note that rather than setting animation: none and transition: none, we instead set the animation-duration and transition-duration properties to a short enough duration that the motion itself is no longer noticable. This is to prevent issues in any case there is a dependency on the animation to run (such as when listening to the animationend event).

Use skip navigation links

2013-05-11T00:00:00Z

Use skip nav links in conjunction with a coherent heading outline and ARIA landmarks. You may need to also implement a JavaScript polyfill for Webkit-based browsers.

It can be frustrating and fatiguing for folks with limited mobility to have to have to repeatedly tab through navigation links to get to the main content of a page. People who use screen readers face similar frustration when the page outline is not well defined. In order to address this issue, WCAG 2.0 has specified a guideline for bypassing repetitive blocks of content. One technique recommended by the W3C is to include a skip navigation link at the beginning of the page, that changes focus to the first element after the repeated content.

Skip nav links are useful for users who use keyboard navigation only, but screen readers now support more sophisticated ways of navigating regions. Specifically, they support heading navigation and ARIA landmarks. You should take advantage of these features by using a clear heading outline and defining page regions, as illustrated in Quick Tip: ARIA Landmark Roles.

Example

<body>
  <a href="#main">Skip to main content</a>
  <nav role="navigation">
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
      <li><a href="/blog">Blog</a></li>
    </ul>
  </nav>
  <main id="main">
    <!-- page specific content -->
  </main>
</body>

Disclaimer: The mechanism by which skip navigation links work had for some time been broken in Webkit-based browsers and has only recently been fixed. Until these browsers release the fixes, you may need to use a JavaScript polyfill to make skip nav links work.

Notes

Jim Thatcher pioneered skip navigation links as early as 1998
An example of a JavaScript polyfill by Nicholas C. Zakas.
An alternative non-Javascript method would be to add tabindex="-1" or 0 to elements that don't normally receive focus. This adds them to the tab order. The bug in Chrome looks to apply to anchors as well. However, the tabindex bypasses the issue.

Using captions with HTML's video element

2013-07-17T00:00:00Z

One of the great things about the internet is the ability to share video.

With HTML we can now use video without the use of Flash. This makes video more accessible as the controls are located in the DOM. However, to do accessible video right, you need to include captions and transcripts.

In addition to making video accessible to those with hearing issues, having a transcript on the page can provide you localization of a video not always available in the local language. Transcripts also give all users an alternate way to access the information presented in a video. Additionally, with a transcript on your page, you may increase your search engine rankings by making your content easily indexed by search engine crawl spiders.

So how do we pull off putting captions into a video after the video has been produced? Fortunately, the video element has a solution for us. We have to provide a transcript file as a track element after the video source files.

<video class="span12 readable" poster="your-video-poster.jpg" controls title="My Movie">
  <source src="your-video.m4v" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"' />
  <source src="your-video.ogg" type='application/ogg' />
  <source src="your-video.webm" type='video/webm' />
  <track src="your-video-transcript.vtt" label="English Captions" kind="subtitles" srclang="en-us" default />
</video>

Many frameworks built on top of the video element make it even simpler to add in captions, like Video.js.

But what do these track files look like?

WebVTT

One of the most commonly-used caption formats is Web Video Text Tracks (WebVTT), which is saved as a file with the extension .vtt. This is a specially formatted text document. It contains each of the cues numbered, followed by the start time & end time and finally the text. It is recommended to include in the text the name of the person talking. Some styling can be included in the text via basic HTML elements like i or b.

We start it by declaring it a WEBVTT file.

WEBVTT

1
00:00:09.000 --> 00:00:11.000
<b>Alice:</b> Curiouser and curiouser.

2
00:00:17.000 --> 00:00:18.000
<b>Rabbit:</b> I told you she was the right Alice!

3
00:00:19.000 --> 00:00:20.000
<b>Mouse:</b> I am not convinced.

Other formats

In addition to the VTT file format, you can also use TTML (Time Text Markup Language) which is a specific XML format that is currently supported in Flash and used by some major properties on the Internet. If you are migrating from Flash, this may be the best choice as you may have the files already.

TTML files look a bit more complex:

<tt xmlns="http://www.w3.org/ns/ttml" xml:lang="en">
  <body>
    <div>
      <p begin="00:00:9.00" end="00:00:11.00">
        Alice: Curiouser and curiouser.
      </p>
      <p begin="00:00:17:00" end="00:00:18:00">
        Rabbit: I told you she was the right Alice!
      </p>
    </div>
  </body>
</tt>

You may also see captions in formats like .srt or others that may work best for your needs.

Transcribing

Now that you know how to implement it, you need to transcribe all of your videos. You can watch, and rewatch, and rewatch them to capture all of the talking perfectly timed (I watched that Alice in Wonderland trailer 30 or 40 times and it is only a minute long).

One way to simplify this process is to use YouTube's auto-generated captions. Simply upload your video to YouTube (you can set it to private) and choose the auto-caption feature. Once these have been created, it should only take one or two reviews of the video to make sure the captions match and correct things like spelling and proper nouns. YouTube then lets you download the caption file in many different formats, including WebVTT and SRT.

There are also services that can completely handle the transcription for you. These will typically start at $1 per minute for transcription with a fee of $0.25 per minute for the needed timestamping. Some also have subscription services.

A few well-reviewed services include:

Getting started with ARIA

2014-05-15T00:00:00Z

ARIA (Accessible Rich Internet Applications), is a specification from the W3C and created to improve accessibility of applications by providing extra information to assistive technologies, such as screen readers, via attributes which could be added to HTML.

Out of the box, screen readers will interpret HTML that conveys accessibility mapping information (e.g. a button but not a div). However, ARIA attributes can provide screen reader users with additional context and greater interactivity with content to correct misused HTML, or to convey information not available in HTML alone.

ARIA, by design, has no effect on how elements are displayed or behave in browsers. It does not add new functionality and is meant to act only as an extra descriptive layer for screen readers. ARIA is also beholden to its host language and must adhere to the rules of what elements it can, and cannot, be used on.

ARIA in HTML specification: Defines how ARIA may be used within HTML.
ARIA specification: Defines ARIA.

ARIA attributes

ARIA attributes are predefined in the spec and are divided into two categories, roles and states & properties. Both can be added directly in the markup or via JavaScript to progressively enhance markup as necessary. The properties and states should be updated as needed based on user interactions. There are rules behind which elements may receive types of ARIA attributes, as well as design guidelines for how and when these should be updated in common interactive widgets.

ARIA Roles: Section of the specification about roles.
ARIA States and Properties: Section of the specification about states and properties.
ARIA Authoring Practices note: Provides guidance on how to use ARIA.

ARIA roles

An ARIA role is added via a role="<ROLE TYPE>" attribute and does not change for an element once set. There are six categories of ARIA roles.

Landmark

Landmark roles identify large content areas and are used by screen readers for navigation. Ideally all content of a document would be placed within a landmark role. Doing so would ensure that all content could be navigated to by use of landmarks. E.g. <footer role="contentinfo">.

Document Structure

Document Structure roles provide a structural description for a section and are typically non-interactive. Some document roles map onto existing HTML tags (E.g. role="form") and are only meant for cases when using the native tag is not possible, or to bridge gaps in support.

Widget roles describe common interactive patterns that currently lack semantic equivalents in HTML, and can be used on their own, or as part of larger, composite widgets. E.g. <div role="tabpanel">.

Window

Window roles, consist of alertdialog and dialog. These roles are meant to be used when creating a sub-window to the primary document. E.g. a modal dialog.

Live Regions

Live Region roles inherit the behavior of aria-live set to either the assertive, polite or off states. These roles should be used if a live region should promote other important role information, or be given an accessible name, beyond just producing a live announcement. E.g. <div role="alert">.

Abstract

Abstract roles are only used by browsers to help organize and streamline a document, and never by developers to mark up HTML. Using an Abstract role in your markup would likley not produce any meaningful information.

States and properties

ARIA states and properties are often used to support ARIA roles that exist on a page. Properties often describe relationships with other elements and for the most part, do not change once they're set. States are more dynamic and are typically updated with JavaScript as a user interacts with a page. It's common to refer to states and properties collectively as just ARIA attributes. Screen readers are notified when attributes change and can announce these changes to users after an interaction takes place.

When to use ARIA

Native HTML semantics should still be used whenever possible, but ARIA is useful when certain design patterns or interactions make it impossible to do so. For example, a complex tabbed-interface has no semantic equivalent with HTML, but a role="tablist" and its related attributes can be added to provide this detail to screen readers.

ARIA is also useful to describe newer HTML elements that may not yet have full cross-browser support or be understood by screen readers.

To create accessible applications, basic principles of semantic HTML, keyboard support, and color contrast should still be the primary focus of developers. ARIA may be used to "fill in the blanks" where web page information isn't understood or available to a screen reader via HTML alone.

ARIA examples

Landmark role

The <nav> element implicitly has a landmark role of navigation allowing screen reader users to navigate directly to this element. Review the article Quick Tip: Aria Landmark Roles and HTML5 Implicit Mapping for more information.

<nav>
  <ul>
    <li>
      <a href="/">Home</a>
    </li>
    <li>
      <a href="/contact">Contact Page</a>
    </li>
  </ul>
</nav>

`aria-labelledby`

<section aria-labelledby="KittensHeader">
  <h2 id="KittensHeader">
    All Abbout Kittens
  </h2>
  <p>
    Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
  </p>
</section>

The <section> element includes the ARIA property aria-labelledby which points to the id of the heading within the section. Screen readers will announce the heading's content when they reach the <section> element, giving users a sense of the content contained in this portion of the document. Note: adding an accessible name to a <section> element promotes it to a role="region" landmark. If this is not desired, then do not provide a <section> with an accessible name.

Role, state, and property together in a Tab control

<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel_1">
    Apples
  </button>
  <button role="tab" aria-selected="false" aria-controls="panel_2" tabindex="-1">
    Oranges
  </button>
</div>
<div id="panel_1" aria-label="Apples" role="tabpanel" tabindex="0">
  ...
</div>
<div id="panel_2" aria-label="Oranges" role="tabpanel" hidden>
  ...
</div>

Each element has an ARIA role and attributes to create a complete Tab Widget. Note: as of June 2019 no screen readers support aria-controls by default.

What is color contrast?

2015-01-05T00:00:00Z

In color theory, contrasting colors, also known as complementary colors, are colors from opposing segments of the color wheel. Colors that are directly across from one another on a basic color wheel provide maximum contrast.

Oftentimes companies implement complementary colors to provide the most contrast in their brand. The IKEA logo uses blue and gold, which are direct opposites on the color wheel, as does the FedEx logo. These allow for maximum recognizability and readability, the latter of which is especially important for web accessibility.

What does this mean for web accessibility?

On the web, the use of complementary colors is about finding shades that provide enough contrast between content and the background for anyone with low vision impairments and color deficiencies.

This doesn't mean colors should only be limited to contrasting colors, but instead that care should be taken to ensure a level of contrast in body text, logos, and essential diagrams or other pieces of content. There are a number of tools to help designers and developers check color contrast, including these listed below:

These tools test your colors against a contrast ratio.

A contrast ratio of 4.5:1 is the minimum Web Content Accessibility Guideline (WCAG) 2 standard for regular sized text. For more information on how these ratios are calculated, there is a link to an article by W3C called "The Contrast Minimum" included in the Further Reading section following the article.

The level to which a pair of colors are contrasted is measured with a grade system, known as "levels of conformance". The highest attainable grade is AAA, which requires a 7:1 contrast ratio. W3C states that because it is not always possible to reach the AAA level of conformance across entire sites, the goal is to get the highest level in crucial areas across a site, such as headlines and body text.

What else can we do?

Aside from using color contrast tools to determine your site's colors, there are some other ways you can keep your site's contrast in mind:

The larger the font and wider the stroke, the more legible it will be with lower contrast. Therefore the contrast requirement for larger font is lower. W3C recommends starting at 18pt regular weight or 14pt bold text.
Provide tools for users to adjust the foreground and background colors of your site on the front end. This is especially helpful for people that need to either switch to a low contrast or a high contrast mode. This gives them more control over the contrast ratio and covers everyone using your site regardless of what kind of vision loss or color deficiency they have.
Steer clear of text-based images and use text wherever possible. If that's not possible, consider using a high resolution for text images. Speaking of text images, don't forget to fill out the alt text.
Ensure that your placeholders in forms also have valid color contrast.

Getting started with NVDA

2015-05-29T00:00:00Z

NVDA is a free and open source screen reader from NVAccess. It is available for the Windows operating system and officially supports Internet Explorer, Firefox, and Chrome web browsers. There is also a ton of braille display support!

NVDA is available for download here: nvaccess.org/download

After everything is installed you can press Ctrl + Alt + n to start NVDA. Quitting NVDA is done by pressing NVDA + q, then Enter at the prompt.

The NVDA modifier key

Each screen reader has a special key or key combination to perform tasks. NVDA’s default keyboard modifier key is the Insert key. So, for example, to start reading a web page, you could press Insert + Down Arrow. As an option, if you are using a laptop you can also use the caps lock key as a modifier. This can be set in the Preferences > Keyboard settings... menu.

Reading text

Here are some basic shortcuts to read text using NVDA.

Command	Description
`Ctrl`	Stop reading
`NVDA` + `Down arrow`	Start reading from current position
`NVDA` + `Up arrow`	Read current line
`Ctrl` + `Left/right arrow`	Read previous/next word
`Ctrl` + `Up/down arrow`	Read previous/next paragraph
`Up` / `Down arrow`	Read previous/next line
`Left` / `Right arrow`	Read previous/next character

Shortcut keys

These shortcut keys can be used to quickly jump between specific elements on a page. Elements can be cycled through backwards by holding shift, then press the shortcut key.

Key	Description
`Tab`	Move to next focusable element
`d`	Navigate through landmarks
`k`	Navigate through links
`h`	Navigate through headings
`1` - `6`	Navigate through headings level 1 to 6
`f`	Navigate through forms
`t`	Navigate through tables
`Ctrl` + `Alt` + `Up` / `Down` / `Left` / `Right` arrow	Navigate table content
`b`	Navigate through buttons
`l`	Navigate through lists
`i`	Navigate through list items
`g`	Navigate through graphics / images

By pressing NVDA + F7, NVDA displays a listing of all elements on the page. This is helpful to quickly skip to a specific area or element on the page. It also helps with testing by gaining an understanding of what each element might sound like to the end user. Do those “read more” links give enough context to be useful?

Descriptive output

If you’re used to using VoiceOver and miss the on-screen text description output, NVDA also has this available as a feature. To enable descriptive text output, check the Tools > Speech viewer checkbox. This will open a new, always-on-top, window with a continuous log of text that is being described by NVDA.

A note on styling

One feature that other screen readers have that NVDA doesn’t is custom focus styles. Others like Apple’s VoiceOver or Google’s Chromevox have a custom focus style for links or for input controls that aid in navigation. NVDA does not have a custom focus style so it is very important to style page elements with the :focus pseudo-class. It’s good to make a habit of adding this whenever the :hover pseudo-class is used. Also, avoid using outline: none as this removes focus styles completely from view.

Use `placeholder` attributes

2016-01-07T00:00:00Z

Don't replace a label with a placeholder attribute. If labels are visually hidden, confirm that placeholders have sufficient contrast.

Form input placeholder attributes are helpful for providing hints to (sighted) users in forms. Often times, due to design decisions, a placeholder is used to replace a more semantic label element. Unfortunately, accessible placeholder browser support isn't complete and placeholders often lack sufficient color contrast by default.

Now, there's nothing wrong with using placeholders - they can still be used. However, they should be used in addition to a label, not as a replacement. What happens when we don't use a label for an input element, is a screen reader will get to that field, but won't have any information for the user on what the input element is for. So the screen reader user doesn't know what information to fill out. Also, a placeholder disappears when the input element is in focus, and can be an issue for people with memory impairments.

Make your forms accessible by using one of the following methods (in order of preference):

Redesign to include a proper visible label
Use aria-label or aria-labelledby to provide assistive text
Visually hide label elements (in an accessible manner)

While we're paying attention to our placeholder text, let's review how to add better contrast:

::-webkit-input-placeholder {
	color: #626262;
}
::-moz-placeholder {
	color: #626262;
}
:-moz-placeholder { /* Older versions of Firefox */
	color: #626262;
}
:-ms-input-placeholder {
	color: #626262;
}

The above CSS assumes that the background for the form controls are #fff. If we test #fff and #626262 in a color contrast tool like Tanaguru Contrast-Finder, the results will approve these colors for valid contrast. You can use your own color for this, but be sure to read about how conformance levels work, and use a color contrast tool to confirm.

In the above CSS, each selector for placeholder text needs to be seperate in their own declaration blocks. The reason for this is due to the prefixes needed for placeholder styles to apply. The browser will read the first selector, and if it's not the prefix for that browser, instead of reading through the rest until one applies, it will ignore the rest. To ensure each browser can find it's own prefixed placeholder text styles, it's necessary to write them each separate as we did above.

Once we have sufficient color contrast in our placeholders, placeholders can be used in addition to labels. Here are two examples of forms where placeholders are used with labels to maintain accessibility.

Labeling

Explicit labeling

<form>
  <label for="your-name">
    Your Name:
  </label>
  <input type="text" id="your-name" name="your-name" placeholder="What's your name?">
  <input type="submit" value="Submit Name">
</form>

Implicit & explicit labeling combined

<form>
  <label for="your-name">
    Your Name:
    <input type="text" id="your-name" name="your-name" placeholder="What's your name?">
  </label>
  <input type="submit" value="Submit Name">
</form>

Note that in the second example above, omitting the for attribute on the label is still valid, but still best practice to include. By keeping the for attribute in place, we're combining both explicit and implicit techniques.

For more about explicit and implicit labeling, check out "Labeled with Love". By adding the for attribute to a label with the same value as the ID for the input element it corresponds to, the label becomes explicitly associated with that input element. Explicit labeling is great for screen reader users and when clicking/focusing that label, it will automatically focus the associated input element.

Create accessible data tables

2016-03-05T00:00:00Z

The semantic purpose of a data table is to present tabular data. Sighted users can quickly scan the table but a screen reader goes through line by line. Proper markup must be added to help the screen reader make the correct associations that a sighted user would.

Example of an accessible data table

<table>
  <caption>Monthly Budget</caption>
  <thead>
    <tr>
      <th scope="col">Month</th>
      <th scope="col">Amount Earned</th>
      <th scope="col">Amount Spent</th>
      <th scope="col">Amount Saved</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">January</th>
      <td>$2500</td>
      <td>$1500</td>
      <td>$500</td>
    </tr>
    <tr>
      <th scope="row">February</th>
      <td>$2700</td>
      <td>$1500</td>
      <td>$700</td>
    </tr>
  </tbody>
</table>

Making an accessible table isn’t hard and can be broken down into two main things.

Add a table caption.
Mark row and column headings using the 'scope' attribute

Table captions

Table captions are added right after the opening <table> tag with <caption>Your caption goes here</caption>.

The screen reader will then say “Table with 3 rows and 4 columns, Monthly Budget” or something to that effect. Without this, the screen reader will just start reading off the values inside the table, which is going to be frustrating and not super useful. Imagine reading an entire table cell by cell and then piecing together what the table is trying to tell you.

Skip CodePen embed.

See the Pen Accessible Data Tables by Franklyn (@franklynroth) on CodePen.

Row and column headings

For sighted users, row and column headings of tables are often highlighted visually. The screen reader will need this information coded into the markup.

Column headers should be marked using scope="col". The scope="col" typically goes on the <th> element. If the <th> is a column like the "Amount Earned", "Amount Spent" and "Amount Saved" in my example, you would put them all as scope="col". This lets the screen reader know that the <th>’s are column headers for that entire column. Column headers should be unique.

Row headers should be marked up using scope="row". The scope="row" is typically put on the first <th> in the row. In this case "January" and "February" would get them. For optimal usability, the row header selected should be sufficiently unique and readable to identify the row.

The screen reader will most likely be able to figure out what is a column header and row header, but assigning this makes it unambiguous to the screen reader on what is a row or column header and how to proceed.

That’s pretty much it on how to make an accessible table. Use them for tabular data, assign a caption and use scope="col" or scope="row".

a11y and a brief numeronyms primer

2017-08-26T00:00:00Z

If you're unfamiliar with the term "numeronym", you may not have realized that a11y isn't just a hash tag, nor is it a hip way to spell ally. Rather a11y is a shorthand for accessibility.

You may have seen "a11y" used as a hash tag on Twitter, or used in a comment, article, used in a comment thread, or written in an article. Since you're reading this right now, you've likely seen it in the name of a certain website about accessibility. Ahem...

How numeronyms work

Unlike abbreviations like FYI (for your information), and PC (personal computer), or acronyms like HTML (hypertext markup language), and JAWS (Job Access With Speech), numeronyms are number-based words. And while you may not be familiar with the term "numeronym" itself, you've likely used them throughout your life.

For instance, "9-1-1" is synonymous with "help", "24/7" means "24 hours a day, 7 days a week", and Y2K is for "year 2000" or "the year 2000 problem." These are all examples of numeronyms.

As illustrated by the previous numeronyms, sometimes they're used to replace entire words with numbers, or they use a combination of letters and numbers to combine words. In the case of a11y, Adrian Roselli explains:

Skip embedded Tweet.

Tip: “a11y” is a numeronym for accessibility. Keep first & last letter, between them put the count of letters removed — in this case eleven.
— aardrian (@aardrian) November 22, 2016

Other numeronyms

The following is a short list of numeronyms you may have seen, or even used, but didn't know what they were called.

i11l: international
i18n: internationalization
l10n: localization
n7m: Numeronym
v12n: Virtualization
W3: World Wide Web
W12t: Web Development
W3C: World Wide Web Consortium

While numeronyms have been around for quite some time, they're not always immediately understandable. As a defining trait of accessibility is about being inclusive, one should keep the following in mind when using a11y:

If you can say or write "accessibility", do so! A11y (often pronounced "A-one-one-Y", "A-eleven-Y", and liberally as "ally") is meant as shorthand for "accessibility". So whenever possible, say "accessibility", even if written as a11y. The best place to use the numeronym are platforms like Twitter where space is limited and every character counts.
A numeronym will be easier to understand the more it is used in context with its true spelling. So if writing, or giving a presentation, be sure to make your audience aware a11y = accessibility as soon as it's introduced. Sure, people will likely be able to piece it together over time, but no reason not to make it immediately clear.
Typefaces can exacerbate the a11y/ally confusion if 1 looks like a lower-case l. Much like "I11l" (a series of Ls?) and "I10n" (lion?). These are other numeronyms that may not be visually optimal with certain typefaces.
Spell checkers and auto-correctors may not know what a11y is and may try to autocorrect it, while mobile keyboards will require switching between alpha and numeric keys to type it out. All minor obstacles, but things to keep in mind when typing it out. Don't want an accidental auto correct or incorrect key press to further muddy the waters.

With all that said, I wouldn't lose any sleep over mispronouncing a11y, or using it as a hash tag without prefacing it with "when I say a11y, I mean accessibility." As mentioned, using "#a11y" to increase awareness on platforms like Twitter, is a good thing!

There are a lot of projects and sites out that that use "a11y" in their name. Obviously there's The A11Y Project, but also Pa11y, Tota11y, and A11ycasts, among many others. All of these different projects don't overtly say "accessibility" in their names, but they make it immediately clear that accessibility is their focus, thus indirectly connecting the numeronym to the concept.

As long as we do our best to make people aware of what numeronyms stand for, and use them appropriately, then their usage and accepted understanding will only grow.

Understanding color blindness

2017-10-18T00:00:00Z

Color blindness is a common genetic condition in which some peoples' eyes can't tell the difference between certain colors. That's not to say these people see the world in greyscale— just that many colors seem identical to one another. Total color blindness is very rare in humans.

Color vision deficiencies (typically grouped together as "color blindness") are not rare. Some form of color blindness affects at least one in twenty people. Wikipedia has a helpful table, based on a journal article from biomedcentral.com. There are several different forms of color blindness. The most common, red-green color blindness, affects around one in twelve men.

Color blindness is less profound than many impairments, but people with color vision problems often face restrictions on certain activities, which vary around the world. For example, Romania prohibits residents who are color blind from driving. The USA doesn't consider color blindness a disability because of workplace discrimination purposes.

Though there are multiple types of color blindness, they are the same in principle. For more information, check out Wikipedia's article on color blindness, which has some excellent descriptions.

What does this mean for accessibility on the web?

To make sure your site is readable for individuals with color blindness, avoid relying on color alone to communicate.

These guidelines are compliant with the WCAG; guideline 1.4.1 covers making content distinguishable using color.

In practice, you can achieve this by choosing colors that are easily distinguished from one another, and by adding secondary visualizations for icons and tasks. For example, say you're using red and green buttons to represent tasks a user has outstanding. It might seem logical to show items that need attention in red, and those that are good in green. One small change, such as overlaying a check mark icon over the "good" or "completed" items, will help communicate which items are approved and those that need attention.

There are cases where this isn't possible. The periodic table, for example, often color-codes the chemical symbols of the elements. When working with tables or other standardised layouts, adding more text or symbols might not be practical.

Available tools

There are a number of online tools to help those without color blindness visualize how accessible their designs are:

These tools are free, simple to use, and can quickly help you make color-accessible choices.

Terminology

OpticianCertification.org maintains a list of eye-related terminology, including links to additional resources.

Browser keyboard navigation in macOS

2017-12-29T00:00:00Z

In order to allow for full keyboard navigation of all focusable interactive elements in macOS Safari and Firefox, you'll need to make sure the following keyboard settings are adjusted.

By default, Apple computers have an operating system (OS) level setting that limits the Tab key to "Text boxes and lists only". This can be confusing, if not frustrating, for those unaware of this setting and expect keyboard focus to be similar to navigating on a Windows machine.

"All Controls" in macOS

Enable "All Controls" in macOS Settings

In the macOS settings, the "All Controls" setting must be enabled for all focusable interactive elements (for instance, links) to be keyboard accessible via the Tab key alone. Enable this feature by going to:

System Preferences
Keyboard
Shortcuts (tab)
macOS Catalina: Select "Use keyboard navigation to move focus between controls" (check box). macOS pre-Catalina: Select "All controls" (radio button). Alternatively, in any macOS version, press Control + F7 (if you're on a laptop you may also need to press the fn key).

After updating this setting you will need to quit and restart your browsers to have the update take effect.

Enable All Controls via Terminal

Run the following command in Terminal to enable keyboard control at the macOS level. This command can be helpful if your organization uses a config script for new employee machines!

defaults write NSGlobalDomain AppleKeyboardUIMode -int 3

Highlight each item in Safari

Additionally for Safari, you can enable the "highlighting of each item" setting in order to use the Tab key to navigate page controls. Enable this feature by going to Safari's:

Preferences
Advanced (tab)
Check "Press Tab to highlight each item on a webpage" (checkbox)

With these changed settings in place you should now be able to use the Tab key to navigate around web pages as expected.

Highlight each item in Chrome

Just like in Safari, a similar setting is available in Chrome. Verify that this feature is enabled by going to Chrome's:

Settings
Appearance
Check "Pressing Tab on a webpage highlights links, as well as form fields" (switch)

Highlight each item in Firefox

Unlike Safari and Chrome, Firefox does not have an option in the settings page for enabling full keyboard control. However, when the "All Controls" setting is enabled in macOS, Firefox may still not send focus to links using the tab key. There is a way to enable keyboard focus of links using advanced configuration options.

Note: When accessibility.tabfocus is set, some forms created with non-semantic HTML elements can behave oddly. For example, the GitHub Gist code editor. If non-semantic HTML elements are inexplicably inaccessible, try resetting this option.

To enable

Open a new tab and go to about:config
Right Click and select New > Integer
Enter the preference name accessibility.tabfocus. Click OK.
Enter the number 7. Click OK.

To reset

Open a new tab and go to about:config
Find the accessibility.tabfocus preference row. (tip: use search field at top of page)
Right Click on the row and select Reset
Restart Firefox

ARIA properties

2018-07-30T00:00:00Z

ARIA 1.1 defines multiple "properties" that can be applied to elements. Unlike ARIA states, most properties are likely to stay static when a page is loaded instead of changing with user interaction.

Properties are inserted into elements as follows: <element aria-property="value"></element> . Example:

<button aria-haspopup="true">
  Options.
</button>

A screenreader will announce this button with 'Options, button menu' or something similar.

There are 38 properties that can be used in ARIA. They fall into 4 categories as defined by the W3C. The categories are:

Widget Attributes: Properties that give information about user input elements.
Live Region Attributes: Properties that are specific to regions that will update while the page is being viewed.
Drag-and-Drop Attributes: Properties of drag-and-drop input elements.
Relationship Attributes: Properties that give information about elements' relationships to other elements.

Note: ARIA is constantly being updated by the W3C. Read the latest working draft.

The properties are given below, along with their category, brief description, and allowed value lists or type of input allowed.

List of ARIA properties

Property (links to WAI-ARIA 1.1 specs)	Category	Description	Allowed Values (default values bolded)
aria-activedescendant	Relationship attributes	Currently active descendant of a composite widget	String - ID of descendant
aria-atomic	Live region attributes	Indicates whether assistive technologies will present the entire element (or only parts of it) when the element is changed	false, true
aria-autocomplete	Widget attributes	Defines if and how autocomplete suggestions are shown	none, both, inline, list
aria-colcount	Relationship attributes	Defines the total number of columns in a table, grid, or treegrid	integer
aria-colindex	Relationship attributes	Defines an element's column index or position with respect to the total number of columns within a table, grid, or treegrid	integer
aria-colspan	Relationship attributes	Defines the number of columns spanned by a cell or gridcell within a table, grid, or treegrid	integer
aria-controls	Relationship attributes	Element(s) controlled by current element	String/list - ID(s) of element(s)
aria-describedby	Relationship attributes	Element(s) that describe the current element	String/list - ID(s) of element(s)
aria-details	Relationship attributes	Identifies the element that provides a detailed, extended description for the object	String/list - ID(s) of element(s)
aria-dropeffect	Drag-and-drop attributes	* DEPRECATED * Defines what functions can be performed when a dragged object is released on the target	none, copy, execute, link, move, popup
aria-errormessage	Widget attributes	Identifies the element that provides an error message for the object	ID reference
aria-flowto	Relationship attributes	Next element(s) in alternate reading order	String/list - ID(s) of element(s)
aria-haspopup	Widget attributes	The element can trigger a popup context menu	false, true
aria-keyshortcuts	Widget attributes	Indicates keyboard shortcuts that an author has implemented to activate or give focus to an element	String
aria-label	Widget attributes	Defines a label for the element (only used when label text not visible on screen)	String
aria-labelledby	Relationship attributes	Element(s) that label the current element	String/list - ID(s) of element(s)
aria-level	Widget attributes	Gives hierarchical level of the element within a structure such as a tree or nested items	Integer greater than or equal to 1
aria-live	Live region attributes	Indicates an element will be updated and gives the type of updates the user can expect	off, assertive, polite
aria-modal	Widget attributes	Indicates whether an element is modal when displayed	false, *true
aria-multiline	Widget attributes	Text box accepts multiple lines of input, not just a single line	false, true
aria-multiselectable	Widget attributes	User can select more than one item in a list	false, true
aria-orientation	Widget attributes	Defines the element orientation	horizontal, vertical
aria-owns	Relationship attributes	Element(s) that are owned by the current element (and not denoted as such by the DOM)	String/list - ID(s) of element(s)
aria-placeholder	Widget attributes	Defines a short hint (a word or short phrase) intended to aid the user with data entry when the control has no value	String
aria-posinset	Relationship attributes	Element's position in a set of items	Integer
aria-readonly	Widget attributes	Element is not editable but is still readable	false, true
aria-relevant	Live region attributes	Defines what constitutes a update requiring notification in a live region	additions text, additions, all, removals, text
aria-required	Widget attributes	User input is required	false, true
aria-roledescription	Widget attributes	Defines a human-readable description for the role of an element
aria-rowcount	Relationship attributes	Defines the total number of rows in a table, grid, or treegrid	integer
aria-rowindex	Relationship attributes	Defines an element's row index or position with respect to the total number of rows within a table, grid, or treegrid	integer
aria-rowspan	Relationship attributes	Defines the number of rows spanned by a cell or gridcell within a table, grid, or treegrid	integer
aria-setsize	Relationship attributes	Number of items in current set	integer
aria-sort	Widget attributes	Gives the direction that items are sorted in a table or grid column	none, ascending, descending, other
aria-valuemax	Widget attributes	Maximum allowed value for a range selector	Number
aria-valuemin	Widget attributes	Minimum allowed value for a range selector	Number
aria-valuenow	Widget attributes	Current value for a range selector	Number (between aria-valuemin and aria-valuemax)
aria-valuetext	Widget attributes	Human readable text alternative to a value for a range selector	String

ARIA states

2018-07-30T00:00:00Z

ARIA 1.1 defines multiple "states" that can be applied to elements. States are likely to change as the user interacts with the page.

States are inserted into elements as follows: <element aria-state="value"></element>. Example:

<span aria-busy="true">
  This element is currently being updated.
</span>

There are 10 states that can be used in ARIA. They fall into 3 categories as defined by the W3C. The categories are:

Widget attributes: States that give information about user input elements.
Live region attributes: States that are specific to regions that will update while the page is being viewed.
Drag-and-drop attributes: States of drag-and-drop input elements.

Note: ARIA is constantly being updated by the W3C. Read the latest working draft.

The states are given below, along with their category, brief description, and allowed value lists. Many states allow for either true or false, and when "undefined" is chosen it means the state is not applicable to the current element.

List of ARIA states

State (links to WAI-ARIA 1.1 specs)	Category	Description	Allowed Values (default values bolded)
aria-busy	Live region attributes	The element is currently being updated	false, true
aria-checked	Widget attributes	The input item is checked	undefined, false, mixed, true
aria-current	Widget attributes	Indicates the element that represents the current item within a container or set of related elements	page, step, location, date, time, true, false
aria-disabled	Widget attributes	The element is visible but not interactive	false, true
aria-expanded	Widget attributes	The element is expanded	undefined, false, true
aria-grabbed	Drag-and-Drop attributes	Deprecated The element is selected for dragging	undefined, false, true
aria-hidden	Widget attributes	The element is invisible to all users (including assistive technologies)	false, true
aria-invalid	Widget attributes	The element contains a value that doesn't match the expected format	false, grammar, spelling, true
aria-pressed	Widget attributes	The button is pressed	undefined, false, mixed, true
aria-selected	Widget attributes	The element is selected	undefined, false, true

Large touch targets

2018-11-21T00:00:00Z

A touch target is the total area a person can click or tap on to activate an interactive element such as a link, input, or button.

Background

Ensuring that interactive elements have sufficiently large touch targets helps people with motor control issues use your website or application. Providing a too-small touch target may make it difficult or impossible for some people to be able to reliably reach the area required to activate the element. Think of it like trying to thread a needle.

The Web Content Accessibility Guidelines (WCAG) specify a minimum size of 44 by 44 CSS pixels for all interactive elements. The exceptions are:

If the interactive element's functionality can be activated by another element of acceptable size on the same page.
If the interactive element is rendered inline within a block of text, such as a link.
If the interactive element's size is controlled by the browser or operating system's UI.
If the interactive element has a design whose presentation requires a certain size or shape.

Only the inline element exception case typically applies to web design. Even then, a recommended larger body type size will help both increase inline touch target size and help accommodate people with low vision.

Small touch targets such as icon buttons can use padding to expand their interactive area without increasing the visible size:

It is also recommended that you add space between large interactive elements, to help prevent people from accidentally clicking or tapping the wrong one.

How to test

To determine the CSS pixel size of an interactive element, use a browser's Inspector feature to check it's computed value.

Two common methods to open a browser's Inspector panel are typing Command/Control + Option + i on your keyboard, or by right clicking on an element on your page and choosing the Inspect option.

If you right click on the interactive element you want to test, it will automatically be highlighted when you choose the Inspect option in the right click menu. For most browsers, this method of selecting an element will also display its CSS pixel height and width:

The inspector also has a Computed panel. It will display the selected element's height and width values, as well as an alphabetical list of the other computed CSS properties. This can be good for checking how the browser ultimately renders your site's CSS.

Resize text

2018-11-26T00:00:00Z

Resize text and make sure everything on the page works. Repeat until you get to 200% zoom. Seems simple? It is.

Essential abilities

Sight: This method tests the visual appearance of content on the page.
Interact with content via a pointer: This method tests mouse interactions.

If you know of a method that doesn't require either of these abilities, please update this Quick Test.

Background

People with low vision may need to increase the size of text in order to use the page.

When someone resizes text, any of the following can break the page:

Text on the page is no longer readable.
Content is lost or truncated.
Interactive elements overlapping each other.

The importance is that relative length units (em, ex, rem, %, vw) are used for text.

How to test

Testing is pretty straightforward.

Initial test in multiple browsers
Resize text
Confirm relative font usage
Choose a browser to do further testing in
Resize text
Check everything

Choosing a browser

Testing text-resize needs initial testing in multiple browsers to confirm that relative units are used correctly in order to conform with WCAG Resize Text (Success Criterion 1.4.4).

Note that you can by mistake give text-resize a pass when testing in Firefox. Text-zoom in Firefox resizes regardless of usage of relative units. Suggested setup is to use two different browsers in initial testing.

Chrome works best, allthough:

Ability to resize text is not obvious.
Does not display the current zoom level.

Edge works well:

Has a smiliar functionality as Chrome.
Increase text size used to only support text-only resize in Reading view but has since improved.

Safari, works but not as well:

Ability to resize text is not obvious.
Does not display the current zoom level.
Safari is only available on macOS.

Firefox is an easy browser for testing further:

It makes resizing text really easy.
It informs you of the current zoom level.
It's available on all popular Operating Systems.
Text-zoom in Firefox resizes regardless of usage of relative units.

Resizing text in Chrome

Copy chrome://settings/fonts to the address bar and then return on your keyboard.
Increase the font size to 32px (default is 16px).

Resizing text in Edge

Copy edge://settings/appearance to the address bar and then return on your keyboard.
Go to section "Fonts" and the option "Customize fonts".
Increase the font size to 32px (default is 16px).

Resizing text in Safari

To increase the font size, press Option + Command + +
To decrease the font size, press Option + Command + -

Resizing text in Firefox

Go to View > Zoom and select Zoom Text Only.
Zoom to 200%.
- Ctrl + +.
- Ctrl + Scroll Up.

Checking everything

After doubling the size of text, verify the following:

All content on the page should still be readable.
- Text shouldn't be too cut off.
- Text needed for understanding shouldn't be truncated.
- Text shouldn't overlap too much.
Interactions still work.
- Buttons, links, and inputs are still usable with mouse, touch, or similar.

Thorough check

Some people might not need to zoom text up to 200%. And there might be a level of zoom below 200% where content doesn't work.

To do a more thorough job, you should check the page at each of the zoom steps the browser makes to see if there are any odd breakpoints.

Exceptions

Images of text won't resize.
Captions over videos likely won't resize.
Using the incorrect html lang code might result in no text-zoom.

Can I zoom everything instead of resizing text only?

It depends on which legislation you have to follow. It's still a good idea to make sure that pages work well with text-only zoom since some people want only the text to be bigger. The usage has increased especially on mobile devices, and statistics from appt.org (2024) show that more than a third of users on Android and iOS devices use this setting.

If you have to conform with the EN-301 549 standard

In the EN-standard 301 459 which the accessibility laws in the EU and Canada points to there's the section 11.7 User preferences which explicitly points out color and font settings to be respected. This means that such things as Dark mode and text-resize is mandated by law.

If you do not have to comply with the EN-301 549 standard

Without going too deep into the Success Criterion 1.4.4 in WCAG, the Success Criterion does not require you to use text-only zoom.

There is even a Success Technique (G142) that says you can pass the Success Criterion by zooming everything.

Creating valid and accessible links

2019-02-15T00:00:00Z

The anchor element is often cited as the main building block of the World Wide Web. It is used to create a link to other pages, to anchors within the same page, to other resources (such as a PDF) or to an email address. How can we make sure they are accessible to everyone?

Start with valid HTML

To be a valid link it must have:

A href attribute: The location of the anchor, page or resource.
Link content Text describing where the link is going, this could be plain text or the alt attribute of an image.
Opening and closing tags.

Write helpful link text

Common unhelpful link texts are 'click here', 'read more' and 'link'. These are problematic because when a person using a screen reader is navigating using links alone these will be read out of context. Where would you expect any of those three links to go if you heard them? It's impossible to know.

Think about restructuring your sentence to remove 'click here' or 'link' and then surround the meaningful part with the link:

<!-- bad -->
To see our documentation <a href="/README.md">click here</a>.

<!-- better -->
We have made our <a href="/README.md">documentation</a> available.

"Read more" can be fixed by including what we will be reading more about:

<!-- bad -->
<a href="/full-article">Read more</a>.

<!-- better -->
<a href="/full-article">Read more - Accessible Landmarks</a>

What about the `title` attribute?

The title attribute is not exposed by all browsers in an accessible way meaning that people using keyboards and touch-only devices will likely never see that information.

If you want to hide content from mobile and tablet users as well as assistive tech users and keyboard only users, use the title attribute.

Using the HTML title attribute - TTPGi

It is therefore not recommended to use the title attribute on <a> elements. If you do use it don't double up on the accessible name of the link, this can produce unnecessary duplicate announcements to some screen readers.

Focus state and keyboard

Some developers/designers see the focus outline of links as ugly and remove them. People navigating using the keyboard require this focus state to keep track of where they are. Best practice is to never remove focus outlines but there are accessible solutions to styling, which are set out in the Quick tip: Never remove CSS outlines.

By default an <a> element with an href attribute can be activated by the Enter key. Be mindful to not override this functionality if attaching other custom scripting. Additionally, it is not expected for the Space key to activate links.

When should you use a `button` instead?

If you have an <a> element that has:

An empty or no href attribute
Scripting attached via the onClick attribute or listeners.

This will probably be triggering an action on the same page, such as opening a menu or toggling content and as such is a much better candidate for the <button> element.

Operating System and Browser Accessibility Display Modes

2020-01-23T00:00:00Z

Most computers, laptops, tablets, smartphones, and web browsers have specialized tools to help people read and take action on the content they display. Some of these tools are display modes, which are pre-defined visual configurations you can tell your device to use.

Five such modes are Dark Mode, Increased Contrast Mode, Inverted Colors Mode, Reduced Motion Mode, and High Contrast Mode. Following is an explanation of each of these mode, who can benefit from it, how to enable it on your device or browser (if supported), and how to work with it in code.

Dark Mode

The User Interfaces (UI) that make up most Operating Systems (OSes) traditionally use lighter colors like white and light grays. Dark Mode is a toggle that instructs this UI to use darker colors, typically black and dark grays.

It is helpful for:

People who want to reduce eye strain in a low or no light environment,
and/or who have certain low vision or photosensitive conditions.

An example of a situation where Dark Mode could be useful is checking your phone in bed with the lights off.

What it affects

Dark Mode will update all UI of the OS that supports it. Most apps developed by the company that creates the operating system will also support Dark Mode. Third party apps, websites, and web apps support Dark Mode only if the people who write the necessary code to enable it.

daverupert.com has support for Dark Mode.

How to enable it

Assumes the latest version of each Operating System or browser.

Android

Go to Settings.
Go to Display.
Set the Dark Theme toggle to the on position.

iOS

Go to Settings.
Go to Display and Brightness.
Select the Dark option for Appearance.

macOS

Go to System Preferences.
Go to General.
Select the Dark option for Appearance.

Windows

Go to Settings.
Go to Personalization.
Go to Colors.
Select the Dark option for Choose your default app mode.

How to target it in code

You can use the prefers-color-scheme media feature to to target Dark Mode in CSS. In the following example, we set our web page to default to black text on a white background, but update to be white text on a black background when Dark Mode is enabled:

body {
  background-color: #ffffff;
  color: #000000;
}

@media (prefers-color-scheme: dark) {
  body {
    background-color: #000000;
    color: #ffffff;
  }
}

Filtered Display Mode

These modes are used to adjust the colors that come out of a device's display. There are two types of Filtered Display Mode: Night Mode and Filtered Colors Mode.

Night Mode

One mode is commonly known as Night Mode. It swaps the intense blue light frequencies with warmer, dimmer colors when activated.

Some people report that removing these frequencies at night helps them sleep because the blue light frequencies mimic the light of the sun. Other people find the colors more relaxing and cause less strain on their eyes. However, it is important to note that the scientific benefits of this kind of mode are still being researched.

It may be helpful for:

People who want to reduce eye strain,
and/or who have difficulty sleeping.

An example of a situation where Night Mode could be useful is checking your email while walking home at night.

What it affects

Night Mode will update all UI of the OS that supports it.

How to enable it

Assumes the latest version of each Operating System or browser.

Android

Go to Settings.
Go to Display.
Set the Night Light toggle to the on position.

iOS

Go to Settings.
Go to Display and Brightness.
Go to Night Shift.
Set the Manually Enable Until Tomorrow toggle to the on position.

macOS

Go to System Preferences.
Go to Displays.
Go to the Night Shift tab.
Check the Turn on until tomorrow checkbox.

Windows

Go to Settings.
Go to System.
Go to Display.
Set the Night Light toggle to the on position.

Other alternatives

f.lux is a third party program available for Windows, Linux, iOS, macOS, and Android.

Filtered Colors Mode

Filtered Colors Mode changes the colors output by the device's display. Colors can be shifted to use different palettes or removed entirely.

It is helpful for:

People who are colorblind,
and/or who have difficulty reading text on the display,
and/or who want to reduce eye strain.

An example of a situation where Filtered Colors Mode could be useful is writing late at night.

What it affects

Filtered Colors Mode will update all UI of the OS that supports it.

iOS set to a grayscale Filtered Colors Mode.

How to enable it

Assumes the latest version of each Operating System or browser.

Android

Go to Settings.
Go to Accessibility.
Go to Color Correction.
Set the Use color correction toggle to the on position.
Select a color filter option from the list that appears.

iOS

Go to Settings.
Go to Accessibility.
Go to Display & Text Size.
Go to Color Filters.
Set the Color Filters toggle to the on position.
Select a color filter option from the list that appears.

macOS

Go to System Preferences.
Go to Accessibility.
Go to Display.
Go to the Color Filters tab.
Check the Enable Color Filters checkbox.
Select a color filter option from the select box.

Windows

Go to Settings.
Go to Ease of Access.
Go to Color Filters.
Set the Turn on color filters toggle to the on position.
Select a color filter option from the select box.

Increased Contrast Mode

This mode is only available on macOS and iOS. It will increase the difference in color values between the gray colors used for the OS visuals, as well as drawing more obvious borders between different UI elements.

This is helpful for:

People experiencing low vision conditions,
and/or who have lower quality displays,
and/or people who may need the difference between different parts of the OS visuals to be more obvious.

An example of one of these conditions could be vision-related issues caused by Glaucoma. Here, the increased contrast and borders may help a person who has blurry central vision and a loss of peripheral vision understand the boundaries of different parts of the interface.

What it affects

Increased Contrast Mode will update all UI elements for macOS and iOS. Most apps developed by Apple will also support this mode. Third party apps that use Apple’s interface library will also support this mode, but custom, nonstandard UI elements will not be supported. Websites and web apps do not support this mode.

Preview.app comparing regular and Increased Contrast Mode.

How to enable it

Assumes the latest version of each Operating System or browser.

iOS

Go to Settings.
Go to Accessibility.
Go to Display & Text Size.
Set the Increase Contrast toggle to the on position.

macOS

Go to System Preferences.
Go to Accessibility.
Go to Display.
Check Increase contrast.

Inverted Colors Mode

When Inverted Colors Mode is activated, the color of every pixel on the screen is reversed. Black becomes white, red becomes turquoise, green becomes purple, etc.

Because it affects all content displayed on the screen, Inverted Colors Mode can be very helpful in situations where a light-colored interface does not provide Dark Mode support. Here, Inverted Colors Mode can force a bright UI into kind of jury-rigged Dark Mode. Keep in mind that the opposite also applies: A dark UI will turn light if Inverted Colors Mode is active.

This is helpful for:

People who want to reduce eye strain in a low or no light environment,
and/or who have certain low vision or photosensitive conditions.

An example of one of these conditions could be someone avoiding triggering a migraine by using Inverted Colors Mode to turn a brightly-colored application they need to use for work dark.

What it affects

Inverted Colors Mode affects all content displayed on the screen: Operating System UI, first and third party apps, and web content.

Safari will automatically invert images when Inverted Color Mode is activate.

How to enable it

Assumes the latest version of each Operating System or browser.

Android

Go to Settings.
Go to System.
Go to Accessibility.
Set the Color Inversion toggle to the on position.

iOS

Go to Settings.
Go to Accessibility.
Go to Display & Text Size.
Set the Smart Invert or Classic Invert toggle to the on position.

macOS

Go to System Preferences.
Go to Accessibility.
Go to Display.
Check Invert colors.

Windows

Go to Settings.
Go to Ease of Access.
Go to Magnifier.
Set the Invert colors toggle to the on position.
Set the Magnifier toggle to the on position.

How to target it in code

You can use the inverted-colors media feature to target Inverted Colors Mode in CSS. In the following example, we invert images and video when Inverted Colors Mode is active. This keeps them looking the way they were intended, while allowing the rest of the UI to change:

@media (inverted-colors: inverted) {
  img,
  video {
    filter: invert(100%);
  }
}

Reader Mode

This mode is a feature found in most web browsers. When activated, it takes the content identified as the primary content of a web page and converts it into a format that is easier to read.

Part of this easier reading experience involves removing most, if not all the surrounding content. This includes things like headers, footers, sidebars, comments, etc.

Many Reader Modes also allow the person using it to configure how this content is presented, including preferences for things like background color, text color, font, line height, and line spacing.

This is helpful for:

People who have certain low vision or photosensitive conditions,
and/or people who have motor disabilities,
and/or who have a cognitive disability,
and/or who want a pleasant reading experience.

An example of one of these conditions could be someone who has Attention-Deficit/Hyperactivity Disorder (ADHD) using Reader Mode to remove distracting animated sidebar features from a news article.

What it affects

Reader Mode is only available in certain web browsers, and may not work on every web page you visit. Each version has its own set of specialized checks it uses to determine what the main content of the page is, and if it can be presented.

Firefox’s Reader Mode applied to a blog post.

How to enable it

Assumes the latest version of each Operating System or browser.

Android Chrome

Install a reading app.

Desktop Chrome

Install a reader view extension.

Edge

In the browser’s Address Bar, activate the Enter Immersive Reader button.

Firefox

In the browser’s Address Bar, activate the Toggle reader view button.

Internet Explorer 11 (Windows 8.1 and up)

In the browser’s Address Bar, activate the Read button.

iOS Safari

In the browser’s Address Bar, activate the Text Resizing button.
Select the Show Reader View option.

macOS Safari

In the browser’s Address Bar, activate the Show Reader View button.

How to target it in code

You can use a combination of HTML elements and attributes, as well as Schema.org microdata to semantically describe the main content of your page. Front end developer Mandy Michael explains this in more detail in her article, Building websites for Safari Reader Mode and other reading apps.

Reduced Motion Mode

With this mode, a person can express a preference for animation to be slowed down, or removed entirely.

It is helpful for:

People who have certain photosensitive conditions,
and/or who have a cognitive or vestibular disability,
and/or who want a distraction-free reading experience.

An example of one of these conditions could be someone avoiding animations that trigger vertigo.

What it affects

Reduced Motion mode affect all OS animations that support it. Most apps developed by the company that creates the operating system will also support Reduced Motion mode. Third party apps, websites, and web apps support this mode only if the people who make it elect to use the special code required to enable it.

How to enable it

Assumes the latest version of each Operating System or browser.

Android

Go to Settings.
Go to System.
Go to Accessibility.
Set the Remove animations toggle to the on position.

iOS

Go to Settings.
Go to Accessibility.
Go to Motion.
Set the Reduce Motion toggle to the on position.

macOS

Go to System Preferences.
Go to Accessibility.
Go to Display.
Check Reduce motion.

Windows

Go to Settings.
Go to Ease of Access.
Go to Display.
Set the Show animations in Windows toggle to the on position.

Web browsers

It is also possible to force most browser-based animations to stop playing via installing specialized browser extensions or JavaScript bookmarklets. Front end developer Scott Vinkle’s Togglific is one such way to go about doing this.

How to target it in code

You can use the prefers-reduced-motion media feature to to target Reduced Motion Mode in CSS. In the following example, we remove CSS animation when Reduced Motion Mode is active:

.my-animated-component {
  animation-duration: 250ms;
  animation-iteration-count: infinite;
  animation-name: jump-and-bounce;
}

@media (prefers-reduced-motion: reduce) {
  .my-animated-component {
    animation: none;
  }
}

High Contrast Mode

This mode prioritizes legibility of content above all else. When activated, it maximizes the contrast between OS content and the background it is placed on top of, even at the expense of the appearance of the UI. High Contrast Mode comes with preset color themes, and also allows you to create your own. This allows someone to select combinations of colors that work best for them.

It is helpful for:

People who have low vision or photosensitive conditions,
and/or who are using their device in an environment with very bright light and glare.

An example of one of these conditions could be someone with cataracts who wants to stay up to date on social media.

High Contrast Mode #1 theme.

What it affects

High Contrast Mode support is a little bit complicated. It is only available for Windows (versions 7 and up). It affects all UI elements of Windows, as well as apps developed by Microsoft. It will also work for most third party apps.

For web content, High Contrast Mode will only work with Internet Explorer (versions 10 and 11) and Edge (any version) for Windows 7, 8, and 8.1. For Windows 10, High Contrast Mode will work with web content on Internet Explorer and non-Chromium versions of Edge (versions 44.19041 and earlier).

Most websites will have at least partial support for High Contrast Mode, with support depending on how they are coded.

How to enable it

Assumes the latest version of each Operating System or browser.

Windows

Go to Settings.
Go to Ease of Access.
Go to High Contrast.
Select a theme from the Choose a theme dropdown and then activate the Apply button.

How to target it in code

High Contrast Mode will automatically be applied to web content described semantically in HTML. For example, paragraphs of text described using the p element will automatically update when High Contrast Mode is activated. It will also update the same way if you use the a element for links, the button element for actions, the input element for form controls, etc.

In situations where the HTML cannot be modified, High Contrast Mode styling can be tweaked. For Internet Explorer versions 10 and 11, you can use the the -ms-high-contrast media feature in CSS. In these situations, you should use a specialized subset of CSS2 system color keywords, as High Contrast Mode theme colors are dynamic.

Edge does not fully support -ms-high-contrast. Instead, new Chromium-based versions of Edge support the forced-colors media query. Because of this, it is important to test using both Internet Explorer and Edge to make sure your High Contrast Mode styling work looks the way it is intended to.

Multiple modes

It is possible to have more than one display mode active at the same time. For example, a device could be set to have Reduced Motion Mode, Increased Contrast Mode, and Dark Mode all working in coordination. This is by design, as it lets a person make their device work in a way that is easy and comfortable for them to operate.

ARIA has perfect support

2020-05-13T00:00:00Z

Accessible Rich Internet Applications (ARIA) is an extension of HTML. It is a technology that adds roles, states, and properties that are designed to help with the accessibility of websites and web apps.

Background

ARIA works by supplementing, adding, removing, or overriding information the browser uses to communicate with assistive technology. For example, adding aria-hidden="true" to a HTML element will tell the browser not to report the element, or any of its children to assistive technology.

aria-hidden="true" can be useful for situations where you want to remove something that might normally get reported, such as a SVG icon inside a button. If the button already has a text label, removing the icon helps make sure that the experience is easy to understand by removing unnecessary information that would otherwise be exposed by the decorative icon:

<button type="button">
  <svg aria-hidden="true" focusable="false">
    <!-- SVG code -->
  </svg>
  Save
</button>

ARIA can also be used for interactive controls such as an accordions, tabs, and modals. A thoughtful, skilled application of ARIA can help communicate things like if an accordion panel is in an expanded state, which tab's corresponding tab panel is currently visible, or what is and is not modal content.

Nearly all ARIA should be inserted and updated dynamically via JavaScript. Very little of it is “hard coded” into the HTML it is manipulating.

There are many ways to add ARIA to your website or web app using JavaScript. You can use “vanilla” JavaScript, or specialized frameworks such as Ember, Angular, React, Vue, Svelte, etc. ARIA is compatible with all these frameworks because it is a standard they observe.

Compatibility issues

All web technology has compatibility issues. Compatibility issues are created when there is an interaction between:

The kind of operating system,
The version of the operating system,
The kind of browser running on the operating system,
The version of browser running on the operating system,
Any modifications a person has made to any of the preceding.

Compatibility issues means there might be discrepancies in how web technology is understood and shown to the person using it. In many cases, it won’t be shown at all.

ARIA is a web technology. In addition to the issues listed previously, it can also have compatibility issues that come from:

The kind of assistive technology being used,
The version of the assistive technology being used.
Any modifications a person has made.

Just because you write code that uses ARIA does not mean the ARIA declarations will work as intended. This is the same as expecting modern JavaScript to work on an older browser such as Internet Explorer 11.

This problem is further complicated in situations where parts of your website or web app use ARIA that relies on different parts of your website or web app that also use ARIA. It can also be affected by newer ARIA features interacting with older features.

Another thing to keep in mind is that many people who use assistive technology specifically use older versions of it. This helps to ensure compatibility issues are kept to a minimum.

Unlike many other other forms of compatibility issues, assistive technology-related compatibility can completely lock a person out of a digital experience, instead of just annoying them.

What you can do about it

Before you write any code

Check if a complicated interaction can be broken down into simpler parts.
Observe the First Rule of ARIA: If there is an existing, relevant HTML element, use that instead.
Familiarize yourself with the other four rules of ARIA.

When writing code

If you have to write ARIA, check its known support.
Use an automated accessibility analysis tool such as WAVE, Axe, or ARC to check for common implementation issues. Be sure to run the analysis with all relevant states (expanded, collapsed, disabled, etc.) triggered.

After you write code

Verify that the ARIA you wrote works as intended with a few different kinds of assistive technology.
Verify that the ARIA you wrote makes sense to daily assistive technology users.

Should you avoid ARIA all together?

No. When used responsibly, ARIA helps people who use assistive technology understand the same experiences people browsing without assistive technology do.

ARIA should be the last tool you pull out of your toolbox, not your first.

Learning common keyboard shortcuts for screen readers

2020-07-24T00:00:00Z

Keyboard shortcuts are often presented to us in a list or a table. Lists and tables are great for some people, while others may be overwhelmed from the sheer number of commands to learn. Sometimes a more visual approach could help some people learn these commands.

Learning with a mind map

Creating a mind map of keyboard shortcuts can help people to learn those shortcuts easier than in lists and tables.

A mind map is a diagram that visually organizes information into groups. Shortcuts that belong to one screen reader for example would be visually branched off into a smaller group. Learning groups of shortcuts can be easier than learning individual shortcuts.

Here's a mind map of the common keyboard shortcuts in popular screen readers:

Mindmap of common screenreader commands. Larger version.

The mind map is not an exhaustive listing of screen reader functionality, but shows many of the common commands to help you get a handle on starting out. For example, to learn more about how to 'list all landmarks', you can follow the mapping of branches to the different screen reader software, where the commands will be listed:

List all landmarks -> JAWS -> R or ;
List all landmarks -> NVDA -> D
List all landmarks -> Narrator -> D
List all landmarks -> VoiceOver iOS -> Two finger twist (the rotor menu)
List all landmarks -> TalkBack -> Swipe up then right (the local context menu)

The shortcuts are taken from Deque on shortcuts and gestures.

Watching other people

Looking up videos on how to do those shortcuts can reinforce that learning and trying them out yourself is even better.

An example of using the 'rotor' menu with VoiceOver on iOS is illustrated the following YouTube video: VoiceOver Rotor Gestures - Ballyland Rotor app

The presenter demonstrates the common hand movements to bring up the rotor menu, as well as other interesting ways. Apple recommends placing two fingers on your device and then rotating them to show the rotor menu, but by watching the video we learn that you can also use other gestures that best suit you:

Touching the screen with your thumb and then flicking with your index finger of the same hand, seen at [0:13] until [0:16] in the video
Touching the screen with one finger on one hand and then using a finger from the other hand to make a dialing movement, seen at [0:17] until [0:24] in the video
Touching the screen with one finger from each hand and making a virtual dialing movement with both fingers rotating in the same direction, seen at [0:25] until [0:30] in the video

Learning with a quiz

Other individuals may learn better testing their memory through a quiz. If creating a quiz may be too time consuming, there is a bookmark available on CodePen.

This quiz bookmarklet works on the Deque screen reader shortcut pages. It replaces shortcuts inside tables into input fields that are ready to fill in. There is no way to submit the quiz to find out the answers, but opening the same page in a new tab can help validate your answers. This bookmarklet can be used on the following pages:

Demonstrating the quiz bookmarklet on the JAWS Deque screen reader shortcuts page:

In an ideal world we would be using common screen readers daily to help us learn through experience. While these learning techniques can be helpful, they may not be right for everyone.

An in-depth guide to ARIA roles

2020-08-20T00:00:00Z

The ARIA specification is divided into categories of attributes, one of which is Roles, and the other being States & Properties. ARIA roles, which are covered in this article, are generally used to describe elements:

that may not exist within HTML,
which may not have full cross-browser support,
which may have implementation gaps in screen readers and other assistive technologies.

For instance, ARIA roles can be useful in situations where native HTML semantics are not understood in legacy user agents (e.g., browsers).

Usage

ARIA roles are added to elements using the role="<ROLE_TYPE>" attribute, where ROLE_TYPE represents the specific role being added. Once an ARIA role is set on an element, it should not be changed, regardless of the state of the element. In some cases, roles have to be paired with the appropriate ARIA state or property. However, this article's examples have reduced markup to limit the scope to just ARIA roles.

ARIA roles are broken down into six categories:

Abstract roles

Abstract roles are only intended for use by browsers to help organize and streamline a document. They should not be used by developers writing HTML markup. Doing so will not result in any meaningful information being conveyed to assistive technologies or to users.

Document Structure roles

Document roles are used to provide a structural description for a section of content. A majority of the available roles in this category resemble available semantic HTML tags and it is recommended to only use them when an appropriate native tag is not available. The roles in this category are also not typically interactive in nature. However, they may be used to contain other roles that are interactive. The following examples of toolbar and tooltip roles, serve as good examples of when to use Document Structure roles to provide information to assistive technologies when the equivalent native HTML tag is not available.

<div role="toolbar">
  <div class="text-characteristics">
    <button>Bold</button>
    <button>Italic</button>
    <button>Underline</button>
  </div>

  <div class="text-alignment">
    <button>Left</button>
    <button>Middle</button>
    <button>Right</button>
  </div>
</div>

<button aria-describedby="notifications-desc">Notifications</button>
<div role="tooltip" id="notifications-desc">View and manage notifications</div>

View the full list of available Document Structure roles.

Landmark Roles

Landmark roles identify content areas within a page. They serve as navigational landmarks for the types of content areas that users may be interested in. These content areas include the page's primary content, collections of navigation links, and search functions to name a few.

Most Landmark roles are also implicitly exposed via specific Grouping and Sectioning HTML elements. For example:

The banner role can be associated with the <header> element
The complementary role can be associated with the <aside> element
The contentinfo role can be associated with the <footer> element

Refer to Quick Tip: ARIA Landmark roles and HTML5 implicit mapping for more details on the above mappings and browser support for them.

<nav role="navigation">
  <ul>
    <li><a href="#a">Dexter</a></li>
    <li><a href="#b">Doctor Who</a></li>
    <li><a href="#c">Futurama</a></li>
  </ul>
</nav>

Search role example

<form role="search">
  <label for="search-input">Search this site</label>
  <input type="text" id="search-input" name="search">
  <input type="submit" name="submit-btn" value="Search" />
</form>

<footer role="contentinfo">
  <p>&copy; 2020 Small Business Ltd. All rights reserved.</p>
</footer>

View the full list of available Landmark roles.

Live Region Roles

Live Region roles are used to inform assistive technologies, such as screen readers, of dynamic changes to page content, so that they can be announced to users. The reason for this is that dynamic changes may be visually noticeable, but likely will be missed by users with low or no vision.

Alert role example

The most commonly used Live Region role is the alert role.

<div role="alert">
  <p>Autosave failed.</p>
</div>

When using the alert role, keep in mind that it should not be a focusable element and it should not require users to close it.

View the full list of available Live Region roles.

Widget roles are used to describe common interactive patterns or those that currently lack semantic equivalents in HTML. In most cases, these interactive patterns will be JavaScript-driven. Widget roles should not be confused with role="widget" which is itself an abstract role.

Tabs role example

A common interactive pattern that relies on Widget roles is the very familiar Tabs pattern. Tabs rely on three Widget roles, namely tab, tabpanel, and tablist.

<div>
  <div role="tablist" aria-label="Fruits">
    <button role="tab" aria-selected="true" aria-controls="apples-tab" id="apples">Apples</button>
    <button role="tab" aria-selected="false" aria-controls="oranges-tab" id="oranges">Oranges</button>
  </div>

  <div role="tabpanel" id="apples-tab" aria-labelledby="apples">
    <p>Apples tab content</p>
  </div>

  <div role="tabpanel" id="oranges-tab" aria-labelledby="oranges">
    <p>Oranges tab content</p>
  </div>
</div>

The tablist role is a composite Widget role, which means it is a container used to manage other contained widgets. It is used to contain the list of tab elements, each of which is an interactive element. When a tab element is activated, it will cause its associated tabpanel container to display.

View the full list of available Widget roles.

Window Roles

Window roles are used when creating sub-windows to the primary application or document. A typical example is a modal dialog. The available Window roles are alertdialog and dialog.

Alertdialog role example

An alertdialog is a dialog that contains an alert message and focus is initially set to an element within the dialog. While the dialog is visible, keyboard and mouse interactions are limited to the elements within the dialog.

<div role="alertdialog">
  <h2>Confirmation</h2>

  <p>Are you sure you want to discard all of your notes?</p>

  <div>
    <button type="button">No</button>
    <button type="button">Yes</button>
  </div>
</div>

Dialog role example

A dialog is a window that separates certain content or UI from the rest of the page. Like the alertdialog role, elements within the dialog can receive focus. While alertdialogs are more often than not modal (confining a user's interaction to the contents of the alert dialog until it is dismissed), a standard dialog can be modal or not. When not modal, people may be able to interact with the contents of the dialog, as well as the primary content of the page, freely.

<div role="dialog" aria-labelledby="dialog-label">
  <h2 id="dialog-label">Dialog Title</h2>
  <p>This is the dialog content.</p>

  <button>Close Dialog</button>
</div>

View the full list of available Window roles.

Create accessible forms

2020-09-16T00:00:00Z

With the world becoming data reliant, it's no surprise how data is the new gold. With the right data, you can improve peoples' lives, find solutions to problems and so on. There are many ways to capture peoples' data but on the web, forms are your go-to solution.

Here are some practical tips on how to write accessible forms.

Always label your form inputs

Labels are a great way to get started with writing accessible forms. They are vital for helping people who use screen readers and other kinds of assistive technology determine what label text go with what input field.

To associate a <label> with an <input>, set the identifier(ID) in the <input> to correspond with the for attribute of the <label>. This is the generally accepted approach.

<form>
  <label for="firstName">First Name</label>
  <input type="text" id="firstName" name="firstName"/>
</form>

Note: Do not to nest <input> inside of <label> because some assistive technology (such as Dragon NaturallySpeaking) do not support it.

Highlight input element on focus

Form insertion carets can be difficult to track. A simple solution is to highlight <input> on focus. This way, people do not have to guess where they are on the form.

input:focus {
  outline: 2px solid royalblue;
  box-shadow: 1px 1px 8px 1px royalblue;
}

Break long forms into smaller sections

Filling long forms can be stressful. This is largely true for almost everyone but particularity for people with AD/HD. Such forms can lead to an increase in Bounce rate which isn't what anyone wants. A simple solution is to break them into smaller sections. This helps make long forms less daunting and easier to understand as it is provided in bits.

The following principles apply for multi-step forms:

Repeat overall instruction on every page.
The forms should be split into logical groups.
The forms should inform the person about the progress thay are making.

Note: There are no hard rules that defines a long form. However, you should consider if the form can be broken down into different logical sections.

Provide error messages

When people encounter errors, they may need help to determine what's wrong and why. A common way forms indicate invalid fields is to change the <input> border color to red which is not ideal. The reason for this is because a change in color alone is not exposed to assistive technologies, so indicating errors in such ways will not inform the person of the error. Also, relying on color alone may also not work for someone who is red/green colorblind.

The following are ways to effectively and accessibly communicate form errors:

Let the person know there is an error.
Let the person access the error, and provide instructions on how to fix it.
Allow the person re-submit the form.

In the code below, there is an empty live region which report errors to assistive technologies. Additionally, each field is followed by a hint which is hidden by default but shown if that field does not validate.

<form>
  <label for="username">Enter a username</label>
  <input type="text" id="username">
  <p class="hint hidden" id="usernameHint" >Your username cannot contain punctuation</p>

  <label for="email">Enter your email address</label>
  <input type="text" id="email">
  <p class="hint hidden" id="emailHint">Please enter a valid email address</p>

  <label for="password">Enter a password</label>
  <input type="password" id="password">
  <p class="hint hidden" id="passwordHint">Your password must be at least 6 characters</p>

  <div aria-live="assertive" id="message"></div>

  <button type="submit">Submit</button>
</form>

.hidden {
  display: none
}

.hint {
  color: red;
}

If validation errors occur, two things happen:

The live region is populated upon form submission, announcing to assistive devices that there are errors.
Each invalid <input> is given an aria-invalid="true" attribute and connected to a hint using an aria-describedby attribute.

Here's the markup for the email field in its invalid state:

<label for="email">Your email</label>
<input type="text" id="email" aria-invalid="true" aria-describedby="emailHint">
<p class="hint" id="emailHint">Invalid email address.</p>

Avoid horizontal form layout unless necessary

Layout attributes a great deal to the usability of a site. With CSS, changing a form's visual layout is possible. However, changing the visual layout create problems for people who rely on the structural layout of the page. Because of this, your forms should have a meaningful and logical sequence. If possible, avoid making your form inputs next to each other. This is because people have to spend a little more time correlating the labels with their elements, resulting in slower form completion.

Summary

Accessible forms are important because they help both individuals and businesses thrive by making sure they collect data from the widest possible audience. This, in the long run, leads to growth.

The following are tips on how to create accessible forms:

Always label your inputs.
Highlight input element on focus.
Break long forms into smaller sections.
Provide error messages.
Avoid horizontal layout forms unless necessary.

Introduction to the Web Accessibility Initiative

2020-10-02T00:00:00Z

The advent of the web brought infinite possibilities. It changed the way we learn, work and socialize because we were no longer limited by real or imagined borders. However there was a problem: Lack of standard guidelines and proper structure. Due to the divergence of individual initiatives the Web Accessibility Initiative (WAI) was created.

Introduction

WAI is one of the initiatives created by the World Wide Web Consortium (W3C) as an effort to improve accessibility on the web.

According to Tim Bernes-Lee, Director of the W3C and inventor of the World Wide Web:

Worldwide, there are more than 750 million people with disabilities. As we move towards a highly connected world, it is critical that the web be usable by anyone, regardless of individual capabilities and disabilities.

WAI pursues accessibility through the following ways:

Ensuring that web technologies support accessibility.
Developing guidelines for web content, applications, browsers, and authoring tools.
Developing tools to evaluate and facilitate accessibility.
Supporting education and outreach on web accessibility.
Co-ordinating with research and development that may impact the future of accessibility on the web.
Promoting harmonized international uptake of web accessibility standards.

Organization

WAI consists of several working groups and special interest groups. Each group works on a specific subject, but they are all in the pursuit of a common goal: improving accessibility on the web. The following are the working and special interest groups :

Summary

WAI was created by the W3C as an effort to improve accessibility on the web. They develop accessibility standards and offer implementation guidance. WAI is made up of several working groups and special interest groups working together for a common goal: improving accessibility for disabled people.

Introduction to WCAG 2.x

2020-10-14T00:00:00Z

The Web Content Accessibility Guidelines (WCAG) are web accessibility guidelines published by the Web Accessibility Initiative (WAI).

The WCAG's goal is to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations and governments internationally. Over time, WCAG has produced various versions of the Web Content Accessibility Guidelines. WCAG 2.0 was published on 11 December 2008, WCAG 2.1 was published on 5 June 2018. WCAG 2.2 is a W3C working draft as of 5 June 2020.

WCAG 2.x

WCAG 2.x consists of 12 guidelines. It is organized around four principles which form the acronym "POUR". They include, but are not limited to:

1. Content must be Perceivable (P).

Provide a text alternative for all non-text content.
Provide synchronized alternatives for multimedia (such as captioned video, audio descriptions etc).
Information and structure must be separate from presentation.
Make it easy to distinguish foreground information from the background (for example: good color contrast).

2. Interfaces must be Operable (O).

All functionality must be operable via keyboard.
Provide users enough time to read and use content.
Do not design content in a way that is known to cause seizures.
Provide mechanisms for users to find content, orientate themselves and navigate through it.

3. Content and controls must be Understandable (U).

Make text content readable and understandable.
Make the placement and functionality of content predictable.
Help users avoid and correct mistakes.

4. Content must be Robust (R).

Support compatibility with current and future user agents.

Layers of guidance

The WCAG provides various ways to help authors meet its standard called "layers of guidance". They include the following :

Guidelines

WCAG 2.x guidelines are categorized into 3 levels of conformance in order to meet the needs of different groups and situations. Under each principle, there is a list of guidelines that addresses the principles.

Success criteria

Under each guideline, there are success criteria that describe specifically what is to be done in order to conform to the standard. Each success criteria is written as a statement that will be either true or false when specific web content is tested against it. A convenient list of the success criteria is also provided.

Techniques

The techniques document provides guidance for web authors and evaluators on meeting WCAG 2.1 success criteria. A convenient list of the WCAG 2.1 techniques can be found here.

Common failures

These are common mistakes that are considered failures of Success Criteria of WCAG 2.x. A comprehensive list of WCAG 2.x common failures is also provided.

What's new?

WCAG 2.1 is the current standard. It was initiated with the aim of improving accessibility guidance for three major groups:

People with cognitive or learning disabilities,
People with low vision, and
People with disabilities on mobile devices.

There are additional success criteria in WCAG 2.1 that are not in WCAG 2.0. They are introduced in What’s New in WCAG 2.1. For a detailed review of WCAG 2.1 , see Web Content Accessibility Guidelines (WCAG) 2.1.

While WCAG 2.0 remains a W3C recommendation, the W3C advises the use of WCAG 2.1 in order to maximize future applicability of accessibility efforts.

Web Content Accessibility Guidelines (WCAG) 2.1 - W3C

In effect, the publication of WCAG 2.1 does not nullify WCAG 2.0 as content that conforms to WCAG 2.0 also conforms to WCAG 2.1.

Summary

The following are important points to remember:

WCAG is a set of accessibility guidelines published by WAI.
WCAG 2.0 and WCAG 2.1 are stable, referenceable technical standards.
They have 12-13 guidelines that are organized under 4 principles: perceivable, operable, understandable, and robust.
Content that conforms to WCAG 2.0 is also compatible with WCAG 2.1.

Enabling keyboard culture with No Mouse Days

2020-10-15T00:00:00Z

Wouldn’t it be great if designers and developers tested their digital experiences for keyboard accessibility on the regular? And by extension, screen reader accessibility? That’s where the #NoMouse challenge and No Mouse Days come in.

The DO-IT Center at University of Washington originally started the No Mouse challenge, complete with its own website, logo, and hashtag to spread awareness about the need for keyboard-accessible websites and applications.

The challenge is pretty straight-forward:

Step 1. Use the Web without a mouse.
Can you access all features? Can you reach and operate all interactive controls? Can you easily tell where you are on the page?
Step 2. Learn more about accessible web design.
Step 3. Spread the Word!

Building on that initiative came No Mouse Days, an npm package that disables the mouse cursor on web pages with CSS. It started as a cheeky joke, and then it actually became popular.

The idea of No Mouse Days was to make it easy to hide the mouse cursor so it would become extremely obvious when a user interface didn’t support the keyboard, perhaps disabling it automatically for front-end development one day a week. If you have further ideas for No Mouse Days or other culture-changing techniques, contributions are always welcome on GitHub and Twitter!

No matter how you go about it, establishing a mouse-free development day at least once a week could work wonders for people who can’t use a mouse at all. You might find interactive controls that aren’t actually interactive for large segments of the population and lacking visible focus outlines which make keyboard navigation difficult.

Surfacing issues with keyboard-support early and often will give teams something to react to, and hopefully dedicated tooling and processes can make it second nature through more inclusive design and development.

Getting started with VoiceOver on iOS

2020-11-23T00:00:00Z

VoiceOver is a screen-reading tool built into Apple Inc.'s iOS. It helps people navigate and use their iPhone without needing to see the screen. First introduced in 2009 with the iPod Shuffle and iPhone 3GS, VoiceOver has been in the picture in every Apple's iOS release ever since.

For developers, it is always a good idea to test out VoiceOver with your project on your chosen testing device.

There is also VoiceOver for macOS - a separate screen reader from VoiceOver iOS. If interested, you can check out Mat Marquis's detailed guide to macOS VoiceOver!

How does VoiceOver work?

On an iPhone, VoiceOver responds to gestures (single tap, double tap, et cetera) and audibly communicates to us all the information we need to know (for example, what we have selected or done, the hints, values and traits of the items).

How to start using VoiceOver on iOS

The easiest way to turn on VoiceOver on your iPhone is to:

Open Settings app on your iPhone.
Select Accessibility.
Under Vision, select VoiceOver.
Turn on VoiceOver.

You can also make it easier to activate/deactivate VoiceOver and use it frequently, by adding an Accessibility Shortcut:

Open Settings app on your iPhone.
Select Accessibility.
Under General, select Accessibility Shortcut.
Select VoiceOver.

Then you can toggle VoiceOver feature on or off by triple clicking the side button (on iPhone X or later). If it is an earlier version of iPhone, triple click the Home button.

You can also ask Siri to turn on VoiceOver on or off instantly by saying "Hey Siri, turn on VoiceOver!" or "Hey Siri, turn off VoiceOver!".

Basic VoiceOver gestures

Here are some common gestures you can use to navigate our iPhone with VoiceOver:

Gesture	Description
Touch the screen anywhere	Hear an item
Drag finger on screen	Explore items
Quickly flick left or right with one finger	Locate items or apps
Double tap	Select and activate app, link or button
Triple tap	Double tap items
Tap once with two fingers	Pause VoiceOver
Swipe up from bottom edge (ends with a haptic response and sound)	Return to Home
Swipe up from bottom edge and keep dragging upward (ends with a second haptic response and higher pitched sound)	Bring up App Switcher
Flick left or right with three fingers	Move through pages in App Switcher
Flick up with three fingers	Force close an app while in App Switcher
Swipe down from top edge of screen	Open Control Center
Swipe up from bottom edge of screen	Quit Control Center

For a more comprehensive list of gestures, check out Apple's official VoiceOver guide!

VoiceOver Rotor

VoiceOver Rotor helps us change how VoiceOver works to suit our needs, whether it is adjusting the volume or speaking rate, selecting Braille Screen Input or more.

VoiceOver Rotor on iOS

When VoiceOver is on, you can open VoiceOver Rotor by rotating two fingers on the screen as if you are turning a dial. Alternatively, you can drag up one finger from one hand and drag down another finger from the other hand.
Keep rotating the Rotor and hear the settings being read aloud until you get the one you want.
Finally, swipe one finger up or down to use the setting.

For example, you can read The A11Y Project's webpage on mobile via headings. First, you rotate the Rotor and stop at Headings setting. Then you swipe one finger up and down to read the webpage headings by headings.

Have fun trying out VoiceOver!

Designing accessible animation

2020-12-22T00:00:00Z

Animation is used in digital products in many ways, such as drawing a user’s focus to a particular area on the screen, providing another layer to a brand’s style with unique and ownable motion design, and adding a spark of unexpected fun to an otherwise robotic interaction.

But designing animation that surprises and delights accessibly is trickier than it sounds.

Dizziness, nausea, disorientation, migraines, and even seizures can all be caused by well-executed yet inaccessible motion design. Because of this, it is critical to design your animation with both aesthetics and accessibility in mind.

Consider parallaxing—large-scale animation where the foreground and background slide past each other at different speeds—and primary navigation based on horizontal scrolling. These effects, especially when dramatic, can trigger the symptoms mentioned earlier.

Animations inherently carry a lot of visual and cognitive weight, so always take into account how the user will be viewing it. Desktop screens are interacted with at a greater distance than handheld devices, therefore any animation should be responsive to avoid overwhelming or distracting users from anything essential. Users with cognitive and learning disabilities may especially appreciate this.

Next, rein in the animations. Endlessly looping animations at any size can be more disorienting than delightful. Specifying the number of cycles it will play, limiting the duration that it plays, or having the animation paused by default will ensure its accessibility. Another way to handle this is by designing controllers that allow the user to pause, stop, or hide the animation altogether.

While it’s essential that accessible animation starts at the design level, there are additional ways developers can implement these tips behind the scenes. We’ve included some links to help show you how.

Use the `tabindex` attribute

2021-01-28T00:00:00Z

tabindex is a global attribute that allows an HTML element to receive focus. It needs a value of zero or a negative number in order to work in an accessible way.

When tabindex’s value is set to zero or a positive number, the element can be navigated to via the keyboard’s Tab key. When it is set to a negative number, its element can be programmatically focused via JavaScript.

Common mistakes

Unfortunately, the tabindex attribute is often misunderstood and consequently misused. Following are some common examples of tabindex use that have a negative impact on accessibility:

Using a positive `tabindex` value

Using tabindex with a value of 1, 2, 3, etc. places the element the tabindex is applied first in the keyboard tabbing order. This can create a confusing experience for anyone who relies on the keyboard’s Tab key to navigate.

Setting a manual tab order

You don’t need to manually set tab order for every page or view on a website or web app. Not only is this extra, unnecessary work that is difficult to maintain, it may deviate from someone’s expected or desired way to navigate. This results an annoying, confusing, and potentially inaccessible experience.

Instead, use appropriate interactive elements (a for links, button for buttons, etc.) and put them in the reading order of the document. Interactive elements come with native browser behavior already built in that allows them to be navigated to via Tab without the need for a tabindex declaration.

Making non-interactive elements focusable

There is a myth that applying tabindex="0" to non-interactive elements (paragraphs, headings, lists, etc.) helps “improve” accessibility by providing a way for a person who uses a screen reader to focus on all the content present in a webpage or web app. Unfortunately, this well-intentioned idea actually does not create a good assistive technology experience.

In the same way that you don’t need to add a tabindex attribute declaration to native interactive elements, you also don’t need to add a tabindex attribute to non-interactive elements for them to work with assistive technologies.

The reason for this is that assistive technologies such as screen readers have other, expected ways of navigating through, and consuming this content. Because of this, adding a tabindex attribute to non-interactive elements creates a few problems. It:

Adds confusion about what is and what is not actually interactive, especially if you cannot see the screen.
Requires extra work for people using keyboards to navigate (and in particular, people who use keyboards who are not using assistive technologies), especially those who have have a motor control disability.
May not announce the element’s name and role, which creates additional confusion about what the element is, how it is supposed to work, and whether or not it has been coded properly.

`tabindex` declared on a non-interactive element nested inside of an interactive element

You do not need to declare tabindex on a child element, provided its parent element is an interactive element. An example of this would be a span element nested inside of a button:

The presence of the tabindex attribute in this code example would affect the order of interactive elements in an illogical way. This creates an annoying and potentially confusing experience for people using keyboards or assistive technology.

Acceptable uses for `tabindex`

Following are some of the more common cases where you do need to use tabindex. In these scenarios it enables the content to be accessible.

Interactive JavaScript widgets and charts

Declarations of tabindex="-1" can sometimes be found on interactive widgets and components that manage focus internally, such as comboboxes or trees, as it allows JavaScript to focus on the element via the focus() method.

Scrollable overflow containers

tabindex="0" should be applied to any non-interactive element that has had CSS’ overflow property applied to it. This will allow people using a keyboard to navigate to, and scroll around the overflowed content.

You will also need to provide:

A label that concisely describes the contents placed within the non-interactive element. The label can either be provided by:
1. An id/aria-labelledby association if it has a visible heading, or
2. An aria-label, if not.
A way to specify what the content contains semantically. This can be provided by:
1. An applicable sectioning element, or
2. A Landmark Role if the content is important enough that people need a quick and easy way to return to it.
3. A group role can also be used if there isn’t a need for quick access.

<div
  aria-labelledby="terms-of-service"
  role="group"
  tabindex="0"
  style="overflow: auto; height: 15rem;">
  <h2 id="terms-of-service">Terms of Service</h2>
  …
</div>

This satisfies WCAG criterion 4.1.2: Name, Role, Value. It allows people to scroll using a keyboard, as well as providing an indication on why they should scroll, and what content they can expect to find within.

When there is not an applicable HTML element

Interactive controls that don’t have a relevant HTML element need a declaration of tabindex="0". An example of this would be a listbox, a widget that “presents a list of options and allows a user to select one or more of them.”

Hopefully this provides enough information to treat tabindex in a responsible, accessible way.

Text resizing in iOS and Android

2021-01-28T00:00:00Z

When you're designing for mobile, it's important to remember that some people will need to change the size of the content to read it easily.

There are so many ways to view content on mobile devices, from zooming in to orienting the screen differently, so a failure to design in a dynamic environment can lead to accessibility issues. There are different ways you can attend to this, whether you're writing an app for iOS or Android.

Considerations for iOS

In iOS, users can use Full Screen Zoom or Window Zoom to magnify parts of the screen. To allow them to resize the type, use dynamic type, which enables your app's type to be resized.

If you manually limit how large your text scales it may cause issues for people who need a bigger font. You want the text to scale dynamically instead of stopping at the point you set, because that size may still not be visible to all people.

Minimum font-size for body text should be 17pt.

Considerations for Android

You can use a tool called the Android Emulator to preview how your app works in the context of different android devices. This can help you stay aware of how people who use different types of androids experience your app.

Again, users can only zoom in on specified areas, so you'll need to use scale-independent pixels to determine the size of your text.

There isn't a tool like Dynamic Type in Android, so you'll need to scale the text at different sizes yourself. Material design has a resource that makes a good starting point.

Minimum font-size for body text should be 16sp:

android: textSize=16sp

You'll also want to remember to make your content container scrollable. If it's not, you'll just cut off the extra content when a person zooms in.

Also consider that apps may contain HTML views. There are a couple things to keep in mind here for accessibility as well.

HTML

In your HTML, make sure to use relative units for responsive design. Here's a resource from The CSS Layout Workshop for applying them to your HTML via CSS. If you don't use relative units, people could end up having to use horizontal and vertical scrolling to view content, which violates WCAG 1.4.10.

Note that a person's pinch-to-zoom capability will be frustrated on mobile < iOS10 if you add maximum-scale=1.0 to the meta element. This could force a person to view your content without zooming, which could make that content unviewable to them.

Dyslexia fonts

2021-02-22T00:00:00Z

Dyslexia is a Phonological Processing disorder. This means it is an issue with language processing, not vision.

Dyslexia is a slight disorder of the brain that causes difficulty in reading and spelling, for example, but does not affect intelligence.

Dyslexia - Oxford Advanced Learner's Dictionary

Dyslexia affects about 1 in 5 people worldwide. Its symptoms range in severity from mild to extreme. It causes your brain to transpose letters, numbers, punctuation, and other characters, which affects your ability to read. This means that making Dyslexic-friendly fonts and typography choices are important things to consider.

Background

When designing fonts, some typographers flip and rotate one character to form other characters. Letters b, p, d and q are usually created using this method. This is because it makes it easier to make the font.

However, this practice may cause problems for people with Dyslexia. It can make some letters, numbers, punctuation, and other characters become indistinguishable. This can make it easy to confuse one character for another. As a result, people with Dyslexia may prefer fonts where all the characters are unique.

The questionable utility of Dyslexic fonts?

Dyslexia fonts are typefaces designed so that each character is unique and distinguishable. Dyslexia fonts also make each character unique by using thicker lines in some parts of the letters, as well as slanting them a bit. They are intended to help people with Dyslexia.

According to recent studies, it has been proven that Dyslexia fonts do not help people read faster and make fewer mistakes. In fact, most people with Dyslexia prefer Comic Sans, Verdana, and Helvetica to other fonts. For a detailed review of the research, see Good Fonts for Dyslexia (PDF).

General font tips

The following are general tips that improve the overall quality of your website's typography:

Font size should be at least 12-14pt or its equivalent. This help people with cognitive disabilities, language and learning disabilities, as well as people with low vision who may not be able to perceive the text.
Larger line spacing improves readability. Proper line spacing makes web content flow smoothly, and ensures that the visually rendered text is presented in such a manner that is perceived without its layout interfering with its readability. According to the WCAG Visual Presentation (level AAA) success criterion, line height (line spacing) should be at least 1.5 times the font size.

Note: There are no hard rules that defines when the line spacing is too loose. However, when the lines of text seem to be visually floating from each other, it is a sign of excess line spacing.

Use a small number of fonts, ideally 1 or 2. This is because multiple fonts makes a website look unstructured and unprofessional. Also, multiple fonts obstructs the flow of content of the web page as people spend time adjusting to each new font. Hence, reducing readability.
Use bold to add emphasis rather than italics. This is because large amounts of italicized text can be difficult to read.
Avoid large amounts of UPPERCASE text. When words are written in all caps, they have a uniform rectangular shape, meaning some readers may not be able to identify words by their shape.
Animated text must be used sparingly and honor reduced motion preferences. This is because animations can be distracting, especially for a person with ADHD.

Summary

This article can be summarized into the following:

Dyslexia affects your ability to read.
Dyslexic fonts may not be effective.
Good typography is more helpful.
Letting a user change their font and type size is important.

Should I use an accessibility overlay?

2021-03-08T00:00:00Z

Due to their technical, social, and moral issues, The A11Y Project does not recommend using permanent overlay plugins. We view these kinds of products as actively harmful, and a step backwards for digital accessibility efforts.

Background

Accessibility overlays have become a controversial topic recently. Let’s clarify what they are, and how they impact accessibility.

An accessibility overlay is JavaScript that is written with the goal of helping to fix accessibility issues on a website or web app. Overlay code is applied after the website or web app is rendered by the browser, to transform it.

Generally speaking, there are two types of accessibility overlays:

Temporary bandage solutions, and
More permanent plugins.

Of the two, the more permanent plugins are incredibly problematic.

Temporary bandage solutions

Temporary bandage solutions have been around for awhile. Historically, they have been used by professional accessibility auditing companies as a stopgap measure.

With the bandage approach, the overlay serves as a temporary measure. It is designed to be used to temporarily fix specific, critical accessibility issues until the underlying website or web app code can be updated.

Think of these kinds of overlays like a bandage. Bandages are not intended to be left on permanently. They are removed after the injury they cover has healed.

Bandage overlays usually have a process to signal when their code should be removed. This process is typically a negotiation between the accessibility auditors and the company who has the inaccessible experience.

Permanent plugins

Permanent plugins are more of a recent phenomenon. Unlike temporary bandage solutions, permanent plugins are designed to be a persistent presence on the inaccessible website or web app. Four examples of permanent plugins are accessiBe, AudioEye, FACIL’iti, and Max Access.

There are numerous issues with permanent plugins. To build off the bandage metaphor, a permanent plugin left on a website or web app for too long will cause the underlying experience to rot.

Ableism

People are not a problem to be solved.

Ableism is a prevalent issue in society. Because of this, there is a lot of misunderstanding about disability, and how it intersects with digital experiences. Permanent plugins attempt to capitalize on this.

Permanent plugins are oftentimes sold to product managers and high-level decision-making employees as an “instant fix” to accessibility issues. They use the threat of a lawsuit as a compelling factor. This does two things. It:

Leaves people who may be more familiar with digital accessibility practices out of the conversation, and
Frames the entire experience as risk avoidance, as opposed to a way of ensuring access.

Quality

Broadly-speaking, there are two kinds of accessibility issues:

Issues that are objective and can be detected by a set of programming rules.
Issues that are subjective and require a human to evaluate.

An example of this is the alternate description of an image. Programming rules can check if an image has an alt attribute. However, programming rules cannot determine if the description is accurate, especially if the image is used for a thematic purpose.

Any permanent plugin that claims to automatically “fix” these kinds of issues cannot deliver on its promises. There are many lawsuits filed against permanent plugin companies reflecting this. Ironically, some permanent plugins actually introduce more accessibility issues when activated.

Sustainability

Temporary bandage solutions come with training, which help the website or web app design and development teams learn how to not repeat the same decisions that created the inaccessible experience.

Permanent plugins do not provide the accompanying training. This means that designers and developers will not grow skill-wise, and the same mistakes will be repeated over and over. If accessibility is viewed as “set and forget,” there is also a high likelihood that the scope of accessibility issues will increase exponentially.

Autonomy

Many permanent plugins override customization and personalization choices a person relies on. These overrides oftentimes do not meet the level of detail and sophistication needed, and may not operate in an expected way.

Privacy

Privacy and disability are closely related. There are many concerns with being identified as an assistive technology user without consent. Some permanent plugin products do not disclose what they do with the information they collect, including selling the information to third parties.

Performance

Due to ableism and the discrimination it creates, there is unfortunately a strong correlation between disability, unemployment, and underemployment. Because of this, there is a decent chance assistive technology may be used on a more inexpensive, lower power device.

Permanent plugins run an extra “layer” of JavaScript over the experience. This slows down a website or web app, and in extreme cases may cause the entire thing to crash. The chance of crashing, or being slowed down to the point of being unusable increases on lower powered devices.

Malware

Malware is software designed to subvert and damage the system it is run on.

Certain permanent plugins include code that attempts to detect and negate automated accessibility-checking tools such as Axe or WAVE. This prevents someone from accurately auditing the actual state of their website or web app.

As they call code that is controlled by someone else, there is also the potential for control over this code to be hijacked. For example, the permanent plugin BrowseAloud was hacked to change its code to mine cryptocurrency.

Avoid using permanent plugins

Instead of using a permanent plugin, we encourage anyone who helps to make digital experiences to:

Learn more about disability and how assistive technology works.
Check your website or web app for accessibility issues.
Test with a wide variety of assistive technology, and assistive technology users.
Incorporate disabled people into your product creation process.

Alternate text and automation

2021-03-23T00:00:00Z

Alternate (alt) text help people who use assistive technology understand images, and are a core part of the Web Content Accessibility Guidelines (WCAG). They require a human’s input to be effective.

To create alternate text, you add an alt attribute to an image that clearly and concisely describes what it is depicting:

<img
  alt="A bowl of tomato soup and a grilled cheese sandwich."
  class="recipe-photo"
  src="/images/lunch.jpg" />

Assistive technology such as a screen reader will read the text provided inside the alt attribute’s opening and closing quotes. It may sound something like:

Image. A bowl of tomato soup and a grilled cheese sandwich.

This allows a person to know an image is present, and what the image’s content contains. With this context, someone using assistive technology can understand the image’s purpose the same way someone who is not using assistive technology would.

It’s up to the person writing the code to add an alt attribute. It’s also up to them to look at the image they’re using and write an accurate description. Many Content Management Systems (CMS) allow the people who use them to include alt text by writing it in a dedicated input field.

WordPress’ alt text input field for uploaded images.

Automation

Technologies such as machine learning and computer vision allow us to guess at what an image is based on its arrangements of pixels. For example, we might show a computer hundreds of thousands of photos of fire hydrants to train it to understand what configurations of pixels look “fire hydrant-ish.”

The idea is that you can take these technologies and apply them to a CMS or other publishing system. The publishing system would ideally then be able to automatically apply alternate text to any image uploaded by an author.

The problem is that automated image description is not a perfect science.

Many of these automated detection technologies are still new and unsophisticated. This means there’s a good chance they haven’t been taught what the image you are uploading is yet. This is especially true for images that contain:

Multiple subjects,
A high degree of detail,
Abstract illustrations,
Foreign languages,
Obscure subject matter, and
Content that is susceptible to algorithmic bias.

This oftentimes leads to inaccurate or incomplete alt text for image content. This means that people who rely on alt text are not getting an equivalent experience.

Highlighting info and thematic content

Image recognition is extremely literal. For example, if you have an image of a family vacation, it may only tell you how many people are present, but not include other relevant details. It’s up to a human to explicitly provide intent about why the image has been included.

Consider the following example:

An automated description may report something along the lines of:

4 people outdoors.

While this is technically correct, it doesn’t communicate the full experience. Consider a human-authored description instead:

A family of four smiling while standing on top of a scenic vacation outlook. The father is taking a selfie while holding his daughter. The mother has her son on her back, and is standing next to him. Behind them the sun is gently setting over an ocean villa.

This discrepancy is even more apparent if an image is used as metaphor to help communicate larger, more abstract themes.

Including relevant detail and abstract themes in alternate text is vital, as they are why image may be included in the first place.

Be wary of false promises

Some companies promise to automatically add accurate alternate text to your image content, either as part of the content creation process, or after the fact as an overlay solution. Because of the issues with automation discussed earlier, they cannot deliver on this promise.

Evidence from Case 1:21-cv-00017-RAL demonstrating an overlay company’s inability to accurately automatically describe an image.

What about screen readers?

Some screen readers utilize image recognition technology. It is important to know two things about this:

Not every screen reader has this capability, and
This feature is a last-ditch effort to understand image content when alt text is not provided.

The image recognition technology used by some screen readers isn’t special. It is susceptible to all the potential issues described earlier. This means that human-authored alt text is still the best option.

What about an image link?

The presence of a link will be announced much as how the presence of an image will. If a link wraps an image element, the image’s alt text will provide a clue for where the link will go. A human’s guidance helps for these circumstances.

An automated description may report something along the lines of:

Link. Image. Map.

While human-authored alt text provides better context:

Link. Image. Paraguay river system.

Every major social media platform includes the ability to add alt text to their images. Some, like Facebook, use an automated image description if none is provided, but they are almost always insufficient.

Memes are oftentimes abstract, where a literal description may not be sufficient to communicate the joke or reference. Veronica Lewis has an excellent post called How to Write Alt Text for Memes that covers the topic extensively.

Training

A more effective, inclusive way to approach alternate text is to educate people on:

What it is,
Why it is important, and
How to write it effectively.

Make checking for concise, accurate alt text part of your editorial, quality assurance, and code review processes. The more these practices are performed, the more second nature they will become.

Fixing contrast issues, on your own site and elsewhere

2021-06-07T00:00:00Z

Insufficient text contrast is the most common accessibility issue on websites today. According to the WebAIM Million report for 2021, 86.4% of home pages world wide have low contrast text. What's worse, this number has been increasing the past three years.

Text contrast issues can by and large be automatically found (and fixed, more on that later), so why do nearly 9 out of 10 sites have contrast issues?

Before we answer that, a quick intro on what text contrast is

When we talk about text contrast, what we mean is the difference between the color of the text and the color that's behind the text. To make sure the text is readable for everyone, you need a certain amount of difference between them.

This difference can be measured using a formula that yields a number between 1 (no contrast, white text on a white background) and 21 (the most contrast possible, black text on a white background). That number is called the "contrast ratio".

The formula is part of WCAG, the Web Content Accessibility Guidelines. How the formula works is not that important, but there are a few numbers you should be aware of. For regular text, you need a contrast value of at least 4.5, and for large text just 3, to pass the text for sufficient contrast. (There are more strict rules available too).

Having to score a 4.5 out of 21 doesn't seem like a very high bar to clear, so why do 86% of websites still have contrast issues?

We could blame our own visual perception for that. For example, here's a text with a contrast ratio of 4.12:

This text does not have enough contrast

For you this might be fine or it might not be, but in any case you're going to have a hard time seeing the difference between it and this text which has a contrast ratio of 4.54:

This text does have enough contrast

One of them does not have sufficient color contrast and would fail an accessibility audit, and the other would pass. And if you couldn't tell them apart that wouldn't be odd, they're very close.

And herein lies a potential pitfall for designers and developers. If we only go by what "looks good", we could inadvertently be making inaccessible choices.

Resolving text contrast issues

There are many design tool plugins and website accessibility checkers that let you test color contrast by manually picking two colors and comparing them. See a list of tools in this earlier article on color contrast.

For the most part, text contrast issues can be automatically found, and as a developer whenever something can be automated I prefer doing that over repeating an action (like selecting elements or clicking around with a color picker) over and over again. The chance of me missing something increases the more I have to repeat myself.

Instead of doing that manual work I wrote a color contrast checker (part of the web browser for developers I build, Polypane) that automatically goes over all text elements, resolves their font size, color and (actual) background and uses that to calculate the contrast ratio.

Still though, that just helps you find inaccessible colors slightly faster. What now? You could use a color picker to pick a darker (or lighter) color and try again, and maybe you have to do that a few times before you get it right. You could push the problem back to your designer and ask them for a new color, or if you have a design system, switch to the next hue in the palette. All of these take you outside of the flow you're currently in.

You can also calculate the nearest color that does have enough contrast. So that's what Polypane does: when it finds a contrast issue, it will suggest the nearest sufficiently contrasting color for you to use. You can copy it or preview it, all without getting out of the flow you're currently in.

Here's what that looks like:

This browser does not support the video element.

Example of a contrast label in Polypane, which shows a failing score, a suggested color that gets applied when you hover over it, and copies that color when you click it.

This is a really useful feature that I didn't wanna keep it locked away in my own product, so it's also available online. When you enter two colors here, you'll get suggestions of similar colors with enough contrast: color contrast checker.

As an author, it is our responsibility to fix these contrast issues and luckily, computers can help us with this a whole lot.

But what if you're not the author?

We can fix our own sites, but what about other people's websites? After all, the chance you're visiting a website that has low contrast text is nearly nine out of ten times.

I realized I could use the code I wrote to automatically fix websites instead. It doesn't make sense inside Polypane, but it would be really useful as a browser extension.

That browser extension is called Fix Contrast and it freely available for Chrome, Edge, Firefox, Vivaldi and Brave, and hopefully soon for Opera and Safari too.

After you install it, it will automatically fix any text with low contrast up to your preferred contrast ratio.

You can pick between two defaults, "medium" and "high" contrast, or pick your own minimum ratio for small and large text. You can also opt to add a background color when the text color can't be changed enough.

This will make the web a more accessible place by fixing an issue for users directly, without having to wait on site authors to resolve their issues. I hope you'll want to use it, and share it with other people for which it would be useful.

As it stands, the extension is available in English and Dutch, and I would love help getting it translated into other languages. If that's something you want to help it, please let me know!

Everyday Accessibility

2021-06-15T00:00:00Z

Even with the best of intentions, you may be making decisions that exclude disabled users. Below are practical, intentional steps you can start today to create and share more accessible social media, digital, and multimedia content.

Watch this post as a video

Social media is central to the world's conversations, so ensure you're not leaving anyone out.

Use capital letters in hashtags

Punctuation helps text-to-speech tools like screen readers speak more accurately, and helps with readability overall. This includes in hashtags, where capital letters help distinguish words.

Key Point: Make it a habit to #UseCapitalLetters rather than #hardtoreadlowercase.

Images of text (such as your favorite quote or saying) can be difficult for people with visual impairments to read and don’t allow people with reading difficulties to leverage text-to-speech read-aloud features. When posting these kinds of images, also write out the text in your post.

Key Point: Typing out the text in an image makes the content more accessible.

Use “alt text” features to describe images

Pictures are significant in social media, but also inaccessible to visually impaired readers unless they have a text-based description. When uploading, find the “image description” or “alternative/alt text” feature in the software to write a description. For sample instructions, review Alt Text for Social Media.

When adding descriptions, don’t write every detail, just enough to ensure everyone can understand your post and share in the image’s meaning. For examples, read Scott Vinkle’s Considerations when writing alt text.

Key Point: Features like Twitter's "Add description" allow adding "alt text" for visually impaired readers.

Limit your emojis

Emojis are great for emphasis and playfulness, but adding too many sounds cluttered with text-to-speech software. Also, when placed unconventionally (such as throughout a sentence) this is distracting and hard to read for those with reading difficulties. Keep your emojis to the minimum needed to make your point, group them together, and move them towards the end of any text.

Key Point:

Avoid writing: I 👏 know 👏 that’s 👏 right 👏!!!

Because text-to-speech reads: I [clapping hands] know [clapping hands] that’s [clapping hands] right [clapping hands] !!!

Documents

Accessibility is not just for the Web, but all of our digital content.

Use a program’s built-in styling features

Assistive technology (AT) doesn't interpret a page or document like people do with their eyes. AT is reading the underlying code markup, which means simply making something look a certain way is not sufficient. When formatting a document or presentation, use the style buttons/options in the program to provide the needed markup; for instance, use the “bulleted list” button rather than just a dash (-) to format a list.

Key Point: Explicitly select format options like "Numbered List" in Microsoft Word to increase accessibility.

Include document structure

Headings (or titles on slides) provide a great way for everyone to preview, skim, and search content. Structure is particularly helpful for blind readers who want to get an overview of the document before reading line-by-line. Include headings throughout a document and titles on every slide, and remember to use the actual “Heading” and “Title” features of the program, not simply stylized text.

Key Point: Using built-in document structure like PowerPoint's "title" placeholders is important for accessibility.

Add alt text to images

Just like with social media, you can add alt text descriptions to images in documents as well. You will typically see an input box to add descriptions grouped with other options when you insert the image.

Key Point: Add image descriptions ("alt text") to images in documents, as in Microsoft Word's Alt Text option.

Use accessibility checkers

Microsoft products (namely Word and PowerPoint) come with a “Check Accessibility” option. Use this to double-check you’ve addressed key accessibility needs.

Key Point: Microsoft's "Check Accessibility" feature helps ensure your document is inclusive.

Audio and Video Content

We can all create multimedia, but let's ensure we don't ignore the best practices.

Have clear audio

Though all of our devices can record audio and video on-demand, sound quality can vary making it difficult for some to hear the content. Be sure to speak as clearly as possible, preferably at a steady pace and reasonable volume, and remove or avoid background noise including echo, empty room effect, humming, or white noise.

Key Point: Using a microphone (even a common corded headset) can help amplify voices and minimize distracting unwanted sounds.

Reduce background music

Instrumental music can enhance content’s quality, but not when it reduces the ability to hear the main speaker. When using background music, keep it to a minimum (such as during an intro) or, if used throughout, ensure it is very low.

Key Point: Consider putting your background music at the volume of a whisper.

Provide text with multimedia

As with images, video and audio can be engaging but also inaccessible without a text equivalent for people who are deaf-blind, having sensory processing disorders, or have hearing impairments. Having media content written out as text is vital for inclusiveness. Text equivalents can include transcripts that type out spoken dialogue, or an article that accompanies a video (as in a video that supplements a news article).

Key Point: Where there’s media, make sure there’s also text.

Avoid flashing content

Content that flashes on the screen more than 3 times per second is dangerous as it can trigger a seizure in some viewers. Use rapid movement sparingly in your videos and ensure nothing flashes. You can use the Trace Center’s Photosensitive Epilepsy Analysis Tool (PEAT) to identify seizure risks in web content and software.

Key Point: Creating content comes with a responsibility to create safe content.

Advocate for Accessibility

We have to work collectively to make inclusion happen.

Seek accessibility features

Actively search for “accessibility” in the tools you use every day — from survey creation sites to website design platforms. Understand what you can do to make sure your output is inclusive.

Key Point: Search for accessibility tips in your favorite systems like on the Zoom "Accessibility" page.

Ask about accessibility

If a system doesn’t offer accessibility features (which is unfortunately very common), reach out to the company about their accessibility policy and roadmaps via the customer support channels. Also, ask about it internally where you work and attend school. Don’t leave this to just your disabled colleagues to take on.

Key Point: Customer pressure can help move accessibility to the front of a company’s roadmap.

Seek to learn more

There’s a lot more to learn and the more allies who know about accessible and inclusive digital practices, the more we can make a big difference for who can participate in our ever-growing digital spaces.

Key Point: You can start your learning journey with The A11Y Project’s Resources Page.

Resources

Download “Everyday Accessibility” posters (PDF, 98kb).

Accessibility and SEO

2021-07-01T00:00:00Z

Search engine optimization and accessibility have a lot more in common than you would think.

Many of the same practices that we use to enable everyone to enjoy our digital experiences also open the doors for search engines.

The intersection of people and search engines

Search engine optimization often gets a bad reputation. In the early years, marketers were adding blocks of keywords into pages by the truck load. Getting to the top of the results by any means necessary was the game. Companies focused on publishing content that was machine-first, not people-first.

The Search Engine Optimization (SEO) industry has since evolved. Marketers who choose to build for people over profit, are those that gain increased visibility online. Catering to bots and algorithm changes, by contrast, is often a game of whack-a-mole and traffic gains are short lived.

Below, we will examine some of the ways accessibility and SEO teams can work together towards a future where everyone wins.

Headings

Search engines crawl through an endless sea of webpages everyday. Assembling information into search results would be impossible without some semblance of structure.

This is where section headings come into play. When implemented to provide meaning rather than styling, headings create an easy way to scan and navigate a document for all people.

<!-- Meh -->
<strong>Animals</strong>
<p>Monkeys, Lions, Bears</p>

<!-- Better -->
<h1>Animals</h1>
<p>Monkey, lions, and bears are all examples of animals.</p>
<h2>Monkeys</h2>
<p>Monkeys are primarily found in tropical rain forests.</p>
<h2>Lions</h2>
<p>All wild lions live on the African continent, with the exception of a small population in western India.</p>
<h2>Bears</h2>
<p>Species of bears exist almost everywhere in the world.</p>

Properly implemented HTML section headings help search engines, too. To determine if a page is relevant to a person's search, Google has to know about the contents of a page. If a page title isn’t present in the code, search engines may use other elements from the document in its place. The level-one heading is generally a good substitute.

Headings can also help pages rank for a broader array of terms. For example, on a product page for a pair of shoes, including
"Reviews" as a section heading may help that page show up for searches like “Product Name + Reviews”, where it may have only ranked for the product name.

<!-- Meh -->
<h1>A cool pair of shoes</h1>
<p>Read the latest <a href="#reviews">reviews</a> for this product.</p>

<!-- Better -->
<h1>A cool pair of shoes</h1>
<h2>Reviews</h2>
<h2>Questions</h2>
<h2>Size Chart</h2>

Taking time to fine tune the outline of the page will lead to better results for people and bots.

Links

Anchor tags are the backbone of the entire internet. They are also the HTML elements that power search engine results. In fact, of the three ways that Google and other companies discover pages on the web (XML Sitemaps, Internal Links, Backlinks), two involve anchor tags.

Anchors do more than send people to a new destination, though. Writing good anchor text paints a clear picture of what’s going to happen next.

Most of us have encountered our fair share of links with the text, "learn more" or "read more." Labels like this cause confusion and suspicion about what interacting with the link will do. Search engines do not have a good idea of where they will end up, either.

For SEO, links are a vote of confidence from other sources around the internet. Links with the text, "footwear," "fashion," and "rubber insoles" are ones that people are more likely to click on. Search engines also find these sites to be more authoritative on the subject than ones whose inbound link text is bursting with "learn more."

Focus on creating descriptive and consistent links between pages. Building pathways between sites and pages that help people first, will pay big dividends for your SEO.

<!-- Meh -->
<a href="/p/shoes-1234">Learn more</a>

<!-- Better -->
<a href="/p/shoes-1234">A cool pair of shoes</a>

Language

Words and phrases that need a PhD to comprehend are rarely found in the search box. In fact, the biggest returns on investment are often gained when we write in plain language.

For example, people who need new heels for their shoes aren't looking for "cobblers near me." They are searching for "shoe repair."

Avoiding long sentences, lingo, and uncommon words also helps people with cognitive disabilities. Complex language choices may exclude them from participating in your offerings.

When in doubt, break your ideas into more manageable chunks. Everyone will appreciate your brevity.

<!-- Meh -->
How search engines crawl, index, and rank pages.

<!-- Better -->
How search engines discover, organize, and display results.

Media

As the internet has evolved, so has the presentation of information. What used to be plain text on the page is now enriched by images, audio, and video. With richness, comes complexity.

For search engines, these new mediums mean new opportunities for engagement. There are four places on Google alone that a published video can show up.

Incorrect implementation of video content can lead to confusion for people and bots. Captions, text alternatives, and unambiguous naming can provide vital context for search engine algorithms. Similarly, poor text alternatives may frustrate someone using assistive technology, by adding too much redundant content to the page.

Digital text remains the most compatible form of information. If you want to capture the attention of all your audience members, search engines included, take the time to get it right.

<!-- Meh -->
<img src="dsc-1234.jpg" />

<!-- Better -->
<img
  src="cool-shoes-1234.jpg"
  alt="Cool shoes with a red upper and sky blue laces."/>

When we work together, everyone wins

Search engine optimization and accessibility professionals do not have to be at odds. In many ways, the goals of the two disciplines are similar, but with different user-agents. Working together to produce code, content, and comprehension for people first, will lead to better outcomes for all.

Reviewing a design for accessibility

2021-08-14T00:00:00Z

I'm a big believer in shifting left: considering accessibility as early in the process as we can. One way we can do this is by reviewing designs for accessibility. This helps us catch anything we've missed before we start developing it.

What to do: annotate

By adding annotations about the semantics and accessibility of elements on a page we can remove barriers to access. The best way to do annotations might be sticky notes on a printout or adding comments on a Figma file, or something else. The important thing is that we want to be clear and explicit.

Here are a handful of things that I've found give good value / effort balance when reviewing a design for accessibility.

Things to check

Page title

Is the page title unique?
Does it concisely describe the page content?

Headings

Are headings used to divide content up in a logical way?
Are the levels shown, without skipping any?

Text alternatives

Do all images (including icons) have a text alternative (using the alt attribute)? You can see WebAIM's guide to alternative text for more about what this is, and what makes good alternative text.
If the image is decorative, is it marked as such (using alt="")? Are we sure it's only decorative?

Link and button text

Does each link describe where we'll go when we follow it? Does each button describe what will happen when we use it?
Where links or buttons have the same text repeated on a page, do they have a longer accessible name that is unique? For example: "View details of Quarter 1 review" instead of "View details".

Standard controls

Do form controls match standard ones (like selects, radio, and checkbox) where possible? If not, is it possible to use a standard control instead?
Are standard controls being used to match the design intent?

Names for form elements

Do all form controls (one input plus one label) have a name? You can reference MDN's article on the <label> HTML element for an example of how the label and input elements work together with the id and for attributes to provide accessible names.
If the name isn't visible, is it shown in an annotation?

Names for groups of form elements

Do groups of related forms controls (such as multiple choice questions) have a name? The name should provide context for the individual questions in the group. Reference the W3C's Web Accessibility Tutorial on Grouping Controls for two approaches on how to do this.
If the name isn't visible, is it shown in an annotation?

Error messages

Are error messages clear and helpful?
Does the message say what went wrong and how to fix it?
Are we not relying on color alone to show the error state?
Are we not referring to sensory characteristics (like shape, size, visual location) in the message?

Summary

Reviewing designs for accessibility is a great way to help designers think more accessibly and to help developers implement more accessibly. We can use annotations to be explicit about the semantic and accessibility features we want on each page. We can use checklists to help us make sure we haven't missed any big things.

If you'd like to learn more about how to improve the experience for everyone who uses your site, check out the WCAG checklist here on the A11Y Project.

Starting a design with accessibility

2021-08-25T00:00:00Z

Designing with accessibility in mind from the start is even better than reviewing a design for accessibility. It helps us consider the wide range of people who use our products and services.

Here are three things we can do to start a design with accessibility.

Do a text-only design

Doing a text-only design to helps us clarify the order and content of a page.

What to do

We can write out the design in text before opening up our favorite design tool (like Sketch or Figma or Adobe XD). Start by making a numbered list with pen and paper, or in a text editor.

Write out the:

Section headings,
Content and function of each image,
Text of each link,
Text of each button, and
Name of each form element.

Why to do it

Writing the content in a numbered list lets us be clear on:

The source order of elements in the HTML. This is the order that a screen reader will read the page in.
The hierarchy of elements on the page. This helps us make choices about layouts on different screen sizes.
The focus order of the page. This helps us make sure it's logical and meaningful.

Writing headings lets us divide the page up into logical sections. Screen reader users often use headings as a way of navigating around a page.

Writing the text of images means we’ll already have alt text (or something that’s a good start on it). It helps us be clear on what information (if any) the image is conveying.

Writing the text for links highlights why “Click here” isn’t helpful link text. Link text should describe where the person goes when they follow the link.

Writing the text for buttons highlights why "Submit” usually isn’t helpful button text. Button text should describe what happens when the person presses the button.

Writing the names of form elements forces us to think of good labels. It forces us to think about the clearest name for each element.

Do an HTML-only design

Doing an HTML-only design helps us clarify the order and content of a page. It also helps us clarify the single function of each interactive element on a page.

What to do

Go through the text-only design and expand it to use only HTML elements. No CSS at this point! That means no presentation (except things with defaults, like heading styles) and no layout (everything will be in one column). MDN's HTML elements reference has a grouped list we can use to find the correct semantic element.

Why to do it

Designing with only HTML gives us the same benefits as writing the page out in a number list. The source order, hierarchy of elements, and focus order of the page are clear.
We can only use one element for one thing, so it forces us to decide what each thing really is. For example: is this a link or a button? If it’s for navigation, use a link. If it’s for an action, use a button.
Designing with HTML forces us to decide on the function of each thing (however we end up styling it). For example: is it a multiple-choice question where we can only pick one? That’s a group of radio buttons.

Go off The Happy Path

“The Happy Path” is the “everything went well and nothing went wrong” scenario. While this is a nice idea, it doesn’t represent the real world and how people and computers interact.

What to do

Review the design and try and break it. Now annotate the design with how to help the person using the page. Can we improve the labels of fields? Can we add help text for fields? What error messages can we show that will tell the person what went wrong and how to fix it?

At this point we could review the design with some presentation applied and consider the CSS we would use. Adding presentational elements will give us more things to check, such as:

Use of color to convey information.
Contrast ratios.
Animation and timing.
States of interactive elements, such as focus styles.

One nice way of trying to break the design is to approach it from a very different direction.

We can ask ourselves “if I was trying to do this wrong on purpose, what would I do?” For example: imagine not entering data in any required fields, or entering the wrong format.
Pick an element and flip, try the opposite. For example: if an error message uses colour, check what it would be like without colour.

Why to do it

Going off the Happy Path forces us to:

Consider error states explicitly. It makes us write error messages up front.
Think about the wider range of human experience. It helps is realize where we might be adding barriers by making assumptions about a person’s abilities.

Summary

Reviewing a design for accessibility is a good way to make sure we ship accessible experiences. Starting a design with accessibility is even better.

Three steps we can start a design and consider accessibility are:

Do a text-only design,
Do an HTML-only design, then
Go off The Happy Path.

This helps us to think about the diverse and complicated range of people who will be interacting with our designs and code. It helps us make sure that we don't put up any barriers for them.

Getting started with Orca screen reader on Gnome desktop environment on Ubuntu 20.04 LTS

2021-09-03T00:00:00Z

Introduction to Orca

Orca is a free, open-source screen reader developed under the GNOME project. Several Linux distributions have it installed by default.

This article will introduce you to the basics of Orca on Gnome desktop environment on Ubuntu version 20.04 LTS. There might be some slight variations if you are using a different desktop environment or using GNOME on a different Linux distribution. You need to consult the manual for your Linux distribution or desktop environment.

Launching Orca

There are three ways you can launch Orca on Ubuntu 20.04 LTS. Below are the descriptions of these three methods.

Use the keyboard shortcut Super + Alt + S.
Type orca on a terminal window and then press the Return key. Alternatively, you can type orca in the Run dialog and press the Return key. You can use the key combination Alt + F2 to open the Run dialog and the ESC key to close it. If you launch Orca using the Run dialog, you can close it by typing the command pkill orca or killall orca on the terminal or in the the Run dialog and then pressing the Return key.
Open the Settings dialog and then select Universal access. You can then toggle the screen reader on or off.

After launching Orca, it will immediately announce the title of the topmost open application window if it is accessible to Orca. Though most applications that come pre-installed with the Gnome desktop environment are accessible, some third-party applications installed by you may not be accessible to Orca.

The Orca Modifier keys

The modifier key used by Orca depends on the keyboard layout. Orca has two keyboard layouts, namely:

Desktop keyboard layout
Laptop keyboard layout

The Desktop keyboard layout is the default keyboard layout. Its Modifier key is the key combination Insert + KP_Insert. KP_Insert is the same as KP_0. If it is your first time using Orca, most likely you are in the Desktop keyboard layout.

The modifier key for the Laptop layout is CapsLock .

You can change the keyboard layout from the preferences section. You can open the preferences dialog from the terminal or from the Run dialog by typing the command orca -s or orca --setup and then pressing the Return key. That command will open Orca and the preferences dialog at the same time.

The Learn Mode

There is a feature in Orca referred to as Learn Mode. It is a valuable feature if you are still learning Orca. It helps you to access the documentation quickly. If you press any key in this mode, Orca will announce the pressed keystroke and the associated Orca command bound to it.

Below is a table showing the keyboard shortcuts associated with the Learn Mode. You need to first turn on Learn mode using the key combination orca modifier + H before using the commands starting in the second row.

Command	Description
`orca modifier` + `H`	Turn on Learn Mode
`F1`	Open Orca documentation
`F2`	Open shortcuts that apply orca-wide
`F3`	Open shortcuts that apply to the currently focused application
`Up` or `Down`	Navigate open list of shortcuts
`ESC`	Turn off Learn Mode

Reading documents and webpages

You can navigate through a document or an application as Orca narrates it for you. You can do that using the application's built-in caret navigation mode. Caret navigation is where a user traverses the application or document and selects text using the keyboard. For example you can use the Left and Right keys to navigate through a document reading one character at a time. Before we look at the basic navigation shortcuts, you should take note of the following:

According to the orca documentation, caret navigation is turned off by default in some Gnome applications. You can toggle it on and off using the F7 key.
Firefox doesn't work with Orca if you launch Orca after launching Firefox according to the Firefox doesn't work with Orca screen reader issue. The workaround is to launch Orca before launching Firefox or restart Firefox after launching Orca.

Below are some of the keyboard shortcuts for navigating through a document, webpage, or application.

Command	Description
`Left` and `Right`	Navigate the document and read by character
`Ctrl` + `Left` and `Ctrl` + `Right`	Navigate the document and read by word
`Up` and `Down`	Navigate the document and read by line
`Shift` with the above commands	To select and unselect text

Conclusion

This article covers the basics of getting started with Orca on Gnome desktop environment running on Ubuntu 20.04 LTS. As already mentioned, there might be slight variations if you are using a different desktop environment or Linux distribution. What we have covered here is just enough to get you started using Orca. You can roll up your sleeves and dive into the Orca documentation to get the full taste of this screen reader.

How I deal with colorblindness as a digital product designer

2021-10-09T00:00:00Z

Colorblindness is any visual anomaly where someone has an altered perception of colors. It can be total or partial. The A11Y Project already has an article that exhaustively covers the different types of color blindness while also providing tools that you can use during your design phases.

In this article, I’d like to tell you what it means to be a colorblind designer and what the main problems are that someone with colorblindness can encounter if they decide to pursue a career as a designer.

Colorblindness from a user’s point of view

During elementary school, like most colorblind people, I discovered that I have deuteranomaly, the most common form of colorblindness: I have a deficit in the sensitivity of my green color receptors. In my offline life, it’s never caused me too much inconvenience, other than the strange color combinations of my clothes.

Growing up and during my introduction to the internet and the first video-game consoles, I encountered more barriers than I had expected. From then on, I started using special filters if an application offered them, and I preferred to browse sites that didn’t over rely on color alone to convey information.

Recently, I was pondering whether most people with colorblindness had problems online or whether I was one of the few people to experience that.

Through deep user research I found two interesting answers: the first is that I wasn’t the only person with colorblindness to have problems online; the second is that, unfortunately, I found many more people than I had imagined.

In light of this, I decided to write a manifesto of ten rules that all designers should follow to create digital products that are more accessible to the colorblind community.

Working as a colorblind designer

In addition to being a colorblind internet user, I am also a colorblind designer. This part of me comes into play when I have to design digital interfaces, either alone or as part of a team. When I’m part of a team, I immediately let people know about my colorblindness to avoid any potential misunderstandings.

But there are many other contexts where my colorblindness manifests itself more, and it can even create slowdowns or serious misunderstandings.

During remote design sessions, we often use Post-it Notes to brainstorm. Many times Post-it Notes of different colors give life to different and common streams of reasoning, while other times Post-it Notes of different colors end up beside one another.

When Post-its with similar colors are placed side by side, my brain can't perceive the color differences between them anymore.

Another element that comes up during design sessions is my constant request for the exact color codes for different interface elements. Unfortunately, it’s not enough for me to know that an element should be made more blue or more red—I need to know what the shades of blue and red are intended to convey because that could be different from what I might imagine.

Working as a digital designer, I continuously refer to screenshots from which I sample color codes. My Mac’s desktop is full of temporary images whose only purpose is so that I can find the right color before I throw them in the trash.

With the type of interfaces that I design, you can usually tell that they’re mine because they have high contrast between colors. And they probably don’t have fancy shades or secondary decorations. I always treat color solely as a decoration because if color alone were to convey information, that could exclude colorblind users.

Improving the work experience

The most important thing that I’ve learned is to immediately let my coworkers know that I’m colorblind. This also helps the other people on the team better understand the types of communication that I’m most comfortable with.

And I continuously seek feedback. When I’m lucky enough to work on projects with other product designers, I ask for their opinion on the work we’ve just done, especially about color and how it could be perceived by noncolorblind people.

Being colorblind is something that for years I’ve considered a limit that would’ve held me back in life—but it’s turned out to be a great strength. It lets me see the world from another point of view. Our goal as product designers should be to work with increasingly diverse teams so that we can create digital products that can better respond to the needs of those around us. And these differences between human beings offer opportunities that we need to make the most of.

Disability: let’s say the word

2021-10-18T00:00:00Z

“I mean, she called you deaf, you’re hearing impaired!”

“Well, actually…”

The words of disability

Growing up, I did identify as ‘hearing impaired.’ My mom was hearing impaired, my brother was hearing impaired, and I was hearing impaired. I never thought much about the word ‘impaired.’ It didn’t bother me or offend me.

Even though I grew up with severe-to-profound bilateral sensorineural hearing loss (try saying that five times fast!), I was not often around other deaf or hard-of-hearing (HOH) people. I had little to no exposure to others’ shared experiences. As such, I did not interact much with members of the Deaf (capital ‘D’) community and had no idea of the preferred terminology.

Discovery

That all changed when Facebook came around and provided us access to many other viewpoints.

The group feature on Facebook was quite popular in the beginning years, and I was eager to talk to people around the world (omg, British people are real!) so I signed up for quite a few groups, one of which was Deaf/HOH. I gave this a cursory glance and moved on to my then favorite “I Judge You When You Use Poor Grammar.” (I was an English major. Cut me some slack, yeah?)

I eventually circled back around to all these groups I had joined, and in the Deaf/HOH group, a topic caught my eye: “Why is it HARD? Why HARD-of-hearing?” In reading through the thread, I saw people discussing the negative connotations of the word ‘hard’ and objecting that something negative was being applied to those with partial hearing loss. (‘Loss’ is another word that is often up for debate in this group.)

Research and themes

I went down a rabbit hole. I came across several threads reinforcing that ‘impaired’ should not be used to describe hard-of-hearing people. I came across the word ‘audism,’ which is the tendency to push non-hearing people into a hearing world. People were “hearies” and “deafies.” People asked for tips on becoming employed and whether they should disclose their deafness.

A predominant theme throughout the group was “Stop trying to fix us! We’re not broken!” Many within the Deaf community viewed cochlear implants as erasing their culture. They would try to convince worried parents not to get them for their young children. In lieu of that, at least ensure their children would learn sign language. In the same vein as “don’t fix us” was “We’re not disabled! We’re DEAF!” Posters would write about not wanting to identify as disabled while also being discriminated against for being deaf.

History and identity

So about that word, ‘disabled.’

Hesitance to use the word ‘disabled’ within the Deaf community stems from a variety of reasons. For this group, they were first Deaf, disabled a reluctant second. That was part of their identity. The neurodiverse community also generally prefers identity first. People in this group might not consider themselves disabled, actually calling their neurodivergence a superpower.

What’s important to note here is that the communities themselves are driving how they are identified, as opposed to someone from the outside looking in trying to define the labels.

Another group of people who hesitate to use the word ‘disabled’ are those who worry it’s a pejorative or insulting. These are usually non-disabled people who, in trying not to accidentally offend, use other potentially offending terms: “differently abled” (immediately “others” us), “range of abilities” or “people of all abilities” (okay, but we’re discriminated against for our disability, are you going to ignore that?), “specially challenged” (again, “others” us), and so on. Note here that the push for labels other than ‘disabled’ is coming from people without a disability.

The #SayTheWord disability hashtag

The #SayTheWord hashtag was created by Lawrence Carter-Long to bring awareness to the actual word ‘disabled’ and to encourage everyone to use it. There are several reasons why non-disabled people may hesitate to #SayTheWord ‘disability.’ Their impression of what entails disability is mostly negative; they think disabled people are sad, lonely, dependent, unhappy. So calling someone ‘disabled’ would imply you think they’re unhappy or incapable.

People also may not realize that disability can be invisible, so they think only people in wheelchairs are disabled, but not the coworker in the cube next to them who needs a lot of time off (due to a hidden disability). Hidden disabilities in particular pose a host of barriers for people. People who have invisible disabilities may find themselves facing skepticism that their disability is ‘real,’ exasperation about the time it may take them to do a task, anger about all the ‘free time’ they get off work. Given stigmas around mental illness such as depression or anxiety, people may hesitate to disclose, for fear that their experience will be minimized or dismissed and their needs ignored.

Breaking down stigmas

In hesitating to use the word ‘disability,’ people are unwittingly reinforcing the stigma that having a disability is a bad thing. It also erases our experiences because of our disabilities. In ensuring we use the word ‘disability,’ we can bring visibility to what all it entails and start breaking down the myriad stigmas associated with it. We can start humanizing the people behind them instead of caricaturizing them as wheelchair or cane users only.

Disability isn’t an inherently bad experience. Disability as a minority group is the only one that everyone can enter in and exit out of during their lifetime. When people break their arm, they’re experiencing a disabling event. However, they may just feel inconvenienced at having to type one-handed or use dictation software. But they’re disabled, even if just for a short while.

Making sure we #SayTheWord can help people relate to the various scenarios that life throws at us that disable us, whether temporarily or permanently. After all, we all age into disability. Disability is something we all will experience, even if we don’t realize it, and there is no shame in that.

#SayTheWord ‘disability’ and when in doubt, ask.

Accessible heading structure

2022-01-03T00:00:00Z

Headings are the backbone of the content of a page. A visitor should be able to scan the webpage using headings to get a good impression of its content.

Heading levels have meaning, especially for screen reader users and search engines. That means one unique first level heading per page, with the other headings representing the page content similar to the index of a book: easily scannable and semantic.

Write well-structured headings, because what is good for your reader, is also good for your SEO.

Headings in HTML

Headings are HTML elements. The main heading, h1, is level 1. The other levels are h2 up to h6. The HTML Living Standard states on headings:

A heading can be used where heading content is expected. Heading content defines the header of a section (whether explicitly marked up using sectioning content elements, or implied by the heading content itself).

The HTML Living Standard, The h1, h2, h3, h4, h5, and h6 elements

In short: use a heading when the content or the page structure requires it.

Best practices summarized

Use one unique h1 per page that describes what that page is about. That h1 preferably starts just above the main content.
Use headings to describe the content below. Do not use an HTML heading just to make the text appear bigger or stand out.
Use heading levels like the index of a book: hierarchical.
Do not choose a heading by its size, but by its level in the context of the content.
Do not skip a heading level from the top down.

Common mistakes:

Using a h2 heading for quotes because of its nice big font size.
Using a h4 heading for the first paragraph of the text because it's just the size of bold text you need.
Exclusively using h2 headings on a web page because all headings are the same size in the designs.
Using multiple h1 headings on a web page.
Omitting headings because the design clearly indicates the start of a new section.
Leaving headings empty (usually a CMS glitch).

What does hierarchical mean?

Hierarchical means arranged in order from most important to least important. The h1 is the most important heading level, the h6 the least.

In practice, for web content, you will use the h1 for the page title, give the most important sections an h2, and, if needed, add an h3 or maybe even an h4 to divide the content in the h2 section.

You only need to start with the h1 if that makes sense for your content structure and design. For example:

    h2 = main menu
h1 = title of a news article
    h2 = subheading in the content of the news article
        h3 = subheading of the h2
            h4 = subheading of the h3
    h2 = subheading in the content of the news article
    h2 = Related news (the aside section)
    h2 = Contact us (in the footer)
        h3 = Address (the address information)
        h3 = Follow us (social media links)

WCAG on headings

What do the Web Content Accessible Guidelines (WCAG) say about headings? They are actually not very specific on this topic.

A few of the WCAG 2 AA success criteria address headings or heading structure directly, for example:

Success Criterion: 2.4.6 Headings and labels. Provide ways to help users navigate, find content, and determine where they are. Headings and labels describe topic or purpose.
Success Criterion: 3.2.3 Consistent Navigation Level. Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user.
Success Criterion: 1.3.1 Info and Relationships. Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. In other words: if it looks like a heading, it should be a heading in the HTML (and not for example text made bold).

In short: use headings to describe content and use them consistently and semantically. This will help all users to better find the content they are looking for.

Only WCAG 2 level AAA demands that headings must be structured. Success criterion 2.4.10 says: Section headings are used to organize the content.

The worldwide web standard is double A (AA), but that doesn't mean that you can't use success criteria that are triple A (AAA) if it's helpful for your users.

A well-organised heading structure helps everyone, especially screen reader users, understand and navigate a web page.

One `h1`

Oh yeah, that old heated discussion. Can I use multiple h1s on a web page? Short answer: No. The h1 is for the page title only.

Having multiple h1s on a web page is bad practice, for accessibility and for SEO. It creates a flat and meaningless structure. But, it's not a WCAG 2 AA violation. The long answer involves a short history lesson.

Using multiple h1s was proposed with the introduction of the HTML Document Outline in HTML5. Each section in the outline could contain an H1. But here's the snag: The Document outline was never adapted by browsers or assistive technology. Therefore the support for multiple h1s was dropped in HTML5.1

If you want to know the full story, please read Computer says NO to HTML5 document outline and A decade of heading backwards by Steven Falkner and There Is No Document Outline Algorithm by Adrian Roselli.

Thankfully the example of multiple h1s in the WHATWG HTML Living standards, has been removed and shows one h1 per page.

Concluding: Multiple h1s on sections to create a document outline is not supported by browsers and therefore outdated.

Use one h1, describing the content of the web page. Structuring the rest of the content with meaningful subheadings. This serves accessibility and SEO best.

`hgroup`

In theory, headings of different levels can be combined using the HTML element hgroup. The hgroup HTML element represents a multi-level heading for a section of a document. It groups a set of <h1>–<h6> elements. But, the MDN documentation on hgroup contains two clear warnings:

<hgroup> should not be used because no assistive technology supports it, and as a result it has a detrimental effect on assistance for headings placed within it.

[...] given that a key purpose of the <hgroup> element is to affect how headings are displayed by the outline algorithm defined in the HTML specification — but the HTML outline algorithm is not implemented in any browsers—then the <hgroup> semantics are in practice only theoretical.

Update August 1, 2022: Steve Faulkner proposed a way to introduce hgroup again, which is promising, in:
Subheadings, subtitles, alternative titles and taglines in HTML

Until browsers add the information themselves do:

Add role="group" and aria-roledescription="Heading group" as attributes to the hgroup element.
Add the subtitles in a paragraph (not a heading) <p aria-roledescription="subtitle">.

Then all information about the structure and connection of the headings group is given for assistive technology in the accessibility tree.

<hgroup role="group" aria-roledescription="Heading group">
  <h1>My heading</h1>
  <p aria-roledescription="subtitle">My subtitle or tagline</p>
</hgroup>

We all navigate by headings (and links) because they stand out. People initially do not read on a webpage, they skim and scan the content for what they want to read. Only if they find what they are looking for, then they start reading.

Make that scan-journey as easy as possible. You can do that by creating a clear and consistent menu structure for the website and a clear heading structure on the web page itself.

People who are blind or visually impaired use a screen reader to read and navigate a website.

With the screen reader you can jump from heading to heading, using a shortcode, and so scan the web page by headings. And you can call a list of headings and scroll through that, to choose the content you want to read from. This is a super fast way to get where you want to read when you can not see the content.

Heading navigation is very common. In the 2021 Screen Reader User Survey by WebAIM it shows that 67.7% use headings to find information. 85.7% of respondents find heading levels very or somewhat useful.

Write your headings and heading structure with that information in mind. Provide information about the content in the page with your headings, also for someone who can not see the page content.

What makes a good heading text?

A good heading text represents the content below. It can be a teaser "Subscribe to our newsletter!" above the subscription form. The page title and subheadings to divide the text into meaningful sections. A short summary of the following content: "Contact information". Or point to additional content "Related news".

Make the heading text descriptive and make them understandable on its own, apart from the context. For people who read the headings list. Let the heading text tell a story about the content of your page.

Heading text length

A screen reader user can call a list of headings and read through them to decide where to start reading on a webpage. There are no accessibility requirements for the length of a heading text.

Next to accessibility, als usability is a factor to take into account. Converting complete paragraphs into a headings results in a horrible screen reader experience. Keep it to the point, descriptive and scannable.

Headings in design

Following are some considerations for using headings in design.

ALL CAPS

Text in all capitals is harder to read. The shape of a word disappears, every word becomes a rectangle. Research shows that all caps text is especially difficult for readers with dyslexia. Make life easy for your readers, don't capitalize all the words.

Damien Sieger did excellent research on readability on the web, including the use of all caps.

Use of headings in the design

As a designer, look at the content structure of a template of a web page, and ask yourself the following questions:

How can a user skim the content by headings?
Does every page have a clear, unique heading above the main content?
Do important sections of content have headings?
Is text just big (looking like a heading) without related content beneath?

Make content scannable by using headings.

Headings in development

Following are some considerations for using headings in development.

Headings in reusable components

Cards, widgets, related content, forms, all components that can be reused on any page and inserted in the content by the theme or by the content manager.

Most components have their own heading and that heading should fit the heading structure of a page. For example: on a page with the latest news, the individual news items have a heading with the level h2. But in a component "related news", the rest "related news" has the heading level h2 and the news items the level h3.

The presentation of the news items can be the same, only the heading level changes. Two possibilities:

Give the content manager the opportunity to add or change a heading while adding a component.
If a component is added by the theme: change the heading level as needed in the code.

Is the logo a heading?

Probably not.

In most designs, the logo is a reoccurring component on every page at the same spot, containing the same text. Often the logo is also a link to the homepage. This is expected behavior and that's totally fine.

But wrapping the logo in an h1, resulting in the h1 being the site name, is not right. Because then, every single page on a site starts with the same h1 text. This is confusing for screen reader users and not informative for search engines.

There are constructions possible to only wrap the logo in an h1 on the homepage and make the logo a link only in the other pages. That could work, but it is not consistent. The best solution is for the designer to add a clear visual and unique h1, also on the homepage.

Headings and ARIA, some discussion

Following are some considerations for using ARIA with headings.

`role="heading"`

With ARIA, it's possible to add the role of heading and the aria-level attribute to an element.

<div role="heading" aria-level="2">
  My Heading
</div>

Or even change the level of a heading:

<h2 aria-level="3">
  My Heading
</h2>

role="heading" is very well-supported by assistive technology.

What are the use cases for this? Because, well, why use ARIA while there is a totally valid HTML element available? Also, the first rule of ARIA states: don't use ARIA when there is a built-in HTML element for the job.

A small inquiry on Twitter shows that developers use ARIA to add or change headings for the following reasons:

Fix the heading structure of legacy code without also needing to adjust the CSS. This is a quick fix that makes sense, when there is no budget to refactor the CSS
Use a div, with a role of heading and an aria-level, to avoid having to remove the native heading CSS styling. This is not the way web developers should approach their code.
Add a level larger than 6, for example in legal documents, which can be very complicated heading wise.

One of the most remarkable reasons mentioned: use aria-headings for SEO. If a heading is needed for the heading structure, but not "good" for SEO, hide the heading from Google by using a role="heading" declaration instead of a native HTML5 heading element.

This creates a shadow heading structure for screen readers, different from the actual HTML heading structure. As there is no evidence that search engines need a different heading structure for presenting content this can be considered as bad practice.

Provide a good heading structure for the reader, and the reader only.

`aria-labelledby`

With aria-labelledby it is possible to give a section or other landmark a name by referring to a heading. See also: Getting started with ARIA.

<section aria-labelledby="sweets-section-heading">
  <h2 id="sweets-section-heading">
    Cupcake Ipsum
  </h2>
  <p>
    Oat cake icing toffee gummi bears jelly beans dessert sweet. Cookie
    tart dragée gummy bears gingerbread wafer bear claw danish. Jelly beans
    fruitcake gummies sesame snaps dragée sweet roll.
  </p>
</section>

Screen reader users can navigate by headings but also by landmarks. This way the name of a landmark can be inherited by a corresponding heading.

Landmark navigation is not that common amongst screen reader users. Labeling may not be necessary for every single section or landmark. While reading through the content the section heading is announced additional to the heading, adding up to the clutter of text a screen reader user hears.

Headings and SEO

How does a good semantic heading structure relate to Search Engine Optimisation (SEO)? Search engines love text, content, written word, to understand the content of a page. Because headings give the content structure, the search engine is better able to understand and index the page properly.

There are many theories and misconceptions about heading structure and SEO. How often do we hear the argument "My SEO expert demanded me to [ … ]", fill in the blanks, as a reason for a heading structure that doesn't make any sense for a blind reader?

Cooper Hollmaier addresses more myths about accessibility and SEO.

There are SEO gurus that really get the point about headings. I'd like to give two quotes from How to use headings on your site by the SEO company Yoast:

Headings help users and search engines to read and understand text. For example, they act as signposts for the readers and make it easier for them to figure out what a post or page is about. Headings also define which parts of your content are important, and show how they’re interconnected.

It’s generally agreed that how you use headings doesn’t specifically impact your SEO. Making minor tweaks to individual headings likely won’t help your performance. However, there are indirect benefits. Using headings creates texts of higher quality that are also easier to read. A better text is better for users, which is better for your SEO.

Write well-structured headings, because what is good for your reader, is also good for your SEO.

Tools

Next to the automated check tools like Axe Devtools, there are some browser add-ons and CMS functionality to quickly check the heading structure in a visual way.

HeadingsMap by Jorge Rumoroso

The browser add-on HeadingsMap by Jorge Rumoroso gives a clear visual presentation of the heading structure and indicates errors for skipping levels and incorrect order.

WAVE Evaluation Tool by WebAIM

This tools shows, embedded within the landmarks, a visual presentation of the heading structure.

WordPress

This CMS provides per page information about the number of headings and a visual heading presentation. This info can be found with the "Details" option (the i-icon) in the toolbar at the top of the edit page functionality.

Use Firefox for accessibility testing

2022-07-17T00:00:00Z

Firefox has become one of the best tools for accessibility audits. Let’s go over Firefox’s accessibility features that you can use today.

Built-in accessibility tools

In this article I’ll discuss The Accessibility Tab, where we will begin and then move through to each component of the Accessibility Tab. First, the Check for issues tab, the Simulate menu, and end with the Show Tabbing Order checkbox. I’ll finish with the Checks and Properties panel.

The Accessibility tab

Whenever you right-click on an element in a page, you can select Inspect Accessibility Properties to directly view that element in Firefox’s accessibility tools. Similarly, if you’re using the Inspector pane in Firefox’s dev tools, you can right-click on any node and choose Show Accessibility Tools to view that node in Firefox’s accessibility tools.

Firefox’s built-in accessibility tool is probably one of the best features in browsers’ dev tools out there now. It shows you the current web page’s accessibility tree, and it has panels for color-contrast checks and the current node’s accessibility-tree properties.

You can traverse the accessibility tree, and as you hover over each node, Firefox will show a tooltip over that node in the viewport with the name of the node and some basic properties. And the Checks and Properties panels can show you all the pertinent information for that node like its color and contrast ratio, name, role, and value.

If you enable this handy feature, Firefox can check for color-contrast issues,it can do its best to try to find keyboard issues, and it can try to find form-label issues. There’s also an All Issues option that will run all of those checks for the page.

Each issue will show you the role and name of the element that has an issue, and the Checks and Properties panels will provide some information and values to help you resolve the issues.

This is a great tool for simulating visual differences. This can simulate:

Protanopia (no red)
Deuteranopia (no green)
Tritanopia (no blue)
Achromatopsia (no color)
Contrast loss

Show Tabbing Order checkbox

Checking Show Tabbing Order will show all the active tab stops like if you were navigating the web page with a keyboard. And you’ll see a small icon with a number indicating what order that element is in the tabbing sequence.

The Checks and Properties panels

The Checks panel shows the developer such information as a color swatch, WCAG level (A, AA, or AAA), Regular or large text (denoted), color contrast ratio and if they meet or fail WCAG guidelines with a link to MDN to learn more about color contrast.

The panel also shows if text labels and names for links meet guidelines, and whether keyboard accessibility is met, if the node has focus able with interactive semantics.

The Properties panel gives you essential information about the node that you’ve selected in the accessibility tree, including the color and contrast for each text leaf and the node’s DOM properties:

name
role
actions
value
DOMNode
description
keyboardShortcut
childCount
indexInParent
states
relations
attributes

For more about each property, you can consult Mozilla’s documentation on the Accessibility Inspector.

The WAVE extension

The WAVE extension from WebAIM is a great tool that you can use to start your testing with by performing quick scans of web pages. This can give you a baseline of what you might expect as you move through Firefox’s accessibility tools.

The first thing that I look at in any accessibility audit is color contrast. Color contrast is still the most common accessibility issue in websites and apps, according to the WebAIM Million Report.

WAVE will also give you a look at color-contrast issues along with other errors and warnings. You can access this on the extension’s toolbar or by right-clicking and choosing the WAVE this page context-menu item.

You can view details of each error, where those errors occur, and the code that’s associated with those errors. The extension also includes a quick reference guide to the WCAG guidelines and links to the success criteria that come up in the errors and warnings it finds.

axe DevTools extension

The next extension that I recommend is the axe DevTools extension. Axe-core is used in other tools such as Lighthouse, Jest, Selenium, and a variety of command-line accessibility checkers.

Maintained by the team at Deque, axe-core and the axe DevTools extension are great tools to help catch some of the things that WAVE doesn’t. Just click the button and scan the page.

A list of issues that it found will automatically come up, and then you’ll see a breakdown of its estimate of each error’s severity: critical, serious, moderate, and minor. I incorporate severity reports into audits I do so that clients can plan a course of attack to resolve issues and triage accessibility errors accordingly.

You’ll get a list of all the issues and a description for each issue. And when you’re viewing the list of errors, you can toggle its list of best practices on or off.

A pane on the right will give you options to highlight the errors and view the elements in question in Firefox’s Inspector tab. Clicking on More Info will open an in-depth entry on Deque University about the error and how to fix it. That pane also includes a code description and some recommendations to help you solve the issue.

Other extensions

Some other browser extensions that I also recommended for accessibility testing:

IBM Equal Access Accessibility Checker (Accessibility checker)
Fontanello (Typography and color-contrast tool)
HeadingsMap (Show, browse, and audit headings’ structure)
Landmark Navigation via Keyboard or Pop-up (Navigate a page using WAI-ARIA landmarks)
Lighthouse (Tool for improving the quality of web pages)
VisBug (Open-source web-design debug tools built with JavaScript: it’s like if there were developer tools but for design)

Summary

There are many tools built in to Firefox that you can use to help with accessibility testing, and there are extensions that can help with testing too. Don’t forget, though: Manual testing is crucial as well. Hopefully, when you use Firefox’s accessibility dev tools, you’ll have just as much success auditing and testing to make sites accessible as I do.

What is WAI? The Web Accessibility Initiative

2022-07-18T00:00:00Z

The Web Accessibility Initiative is W3C's effort to improve accessibility of the Web for people with disabilities.

What is the World Wide Consortium?

In order to know about the Web Accessibility Initiative, we must first talk about the World Wide Consortium, also known as W3C.

Founded in 1994 and currently led by director Tim Berners-Lee and CEO Jeffrey Jaff, W3C is an international community where organizers develop international standards for the Web.

As described by W3’s website, “W3C's mission is to lead the Web to its full potential.”

Organizers from all around the world, involved in many different fields, join W3C to develop guidelines that ensure long-term growth for the Web. The Web Accessibility Initiative is one initiative that was launched by W3C.

What is the Web Accessibility Initiative?

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

W3C launched The Web Accessibility Initiative, (WAI), in 1997, with support from the White House. The Web Accessibility Initiative’s main goal is to make the internet accessible for people with disabilities.

WAI brings people from disability organizations, governments, and research labs from all around the world to develop guidelines and resources to make the Web accessible to people with disabilities. This includes: auditory, cognitive, neurological, physical, speech and visual disabilities.

In short, WAI develops accessibility standards and offers implementation guidance.

As described by W3C Website, WAI “pursues accessibility of the web through these primary activities”:

Ensuring that W3C standards support accessibility
Developing accessibility guidelines for web content and applications,
browsers, and authoring tools
Developing resources to improve web accessibility evaluation
processes and tools
Supporting education and outreach on web accessibility
Coordinating with research and development that may impact future
accessibility of the web
Promoting harmonized international uptake of web accessibility
standards

Two best examples of WAI’s significance in everyday technology life are the Web Content Accessibility Guidelines, (WCAG) and Accessible Rich Internet Applications (WAI-ARIA) Recommendations that were created by members of WAI.

Web Content Accessibility Guidelines, (WCAG) and Accessible Rich Internet Applications (WAI-ARIA) Recommendations:

WAI’s effort created guidelines for developers, designers and people in tech to use every single day. Some of the most used guidelines and applications have been WCAG and WAI-ARIA.

Web Content Accessibility Guidelines, or WCAG is a benchmark for web accessibility. WCAG was created with a goal to clearly define technical standards and unifying accessibility standards. WCAG’s standards are categorized under 4 principles.

Perceivable

People should be able to identify content and elements by means of their senses. For example, if a website's navigation changes from page to page, they will have to relearn the navigation of the site, which will not be a great experience.

Operarable:

People should successfully use controls, buttons, navigation, and other interactive elements on the page. One example of this would be that websites should be operable by a keyboard and the page should have the same functionalities it has when a mouse is used to navigate.

Understandable

People should be able to comprehend the content and learn from your website. One example of this would defining abbreviations or jargon for the reader.

Robust:

Websites should be able to be accessed by a wide variety of technologies. For example, websites should be accessible for screen readers, as well as many different browser versions.

Each WCAG guideline has success criteria broken down to three standards, A, AA, and AAA. AA is considered ideal support, and AAA is typically reserved for specialized audiences.

Accessible Rich Internet Applications

Accessible Rich Internet Applications, or WAI-ARIA is also a guideline that was created by WAI to provide an accessible experience for custom coded interactive experiences. In particular, WAI-ARIA gives guidance on how to create accessible dynamic content and user interface components.

For example, ARIA can help developers divide the page into sections, similar to a table of contents in a book, so it’ll be easier for people to navigate the page. ARIA defines ways for functionality of the assistive technology. With the help of WAI-ARIA guidance and rules, developers can make websites accessible to all users.

Currently WAI-ARIA version 1.2 is under development.

Interested persons can join one of many WAI working groups or interest groups to be part of the process to make websites accessible to all.

Working groups and interest groups:

Purpose of WAI is to bring together members with different backgrounds to contribute to making websites more accessible. Web Accessibility Initiative’s working groups develop accessibility guidelines. People in the industry can join and participate in.

Some of the working group and interest groups listed on their web site are as follows:

Accessibility Guidelines Working Group (AG WG) (formerly the Web Content Accessibility Guidelines Working Group)
Accessible Platform Architectures (APA) Working Group
Accessible Rich Internet Applications (ARIA) Working Group
Education and Outreach Working Group (EOWG)
WAI Interest Group (WAI IG)
WAI websites, explains how interested future members can join WAI to promote and develop accessible web. No matter your background, there is a group or interest group you can contribute.

Takeaways

The Web Accessibility Initiative was launched by the World Web Consortium.

WAI develops accessibility standards and offers implementation guidance.

WAI is a group of people all around the world that contribute ideas on how the internet can be more accessible for people with disabilities. Members who are interested in joining can find more information on the W3C website.

WAI touches most of the accessibility work that has been done. For example, designers and developers look for WCAG standards to see if their website is accessible or not. Developers also use WAI-ARIA’s guidance to know whether or not some interactions are accessible.

Web Content Accessibility Guidelines, (WCAG) and Accessible Rich Internet Applications (WAI-ARIA) Recommendations are some examples of WAI’s guidance on web accessibility.

Blind people need to be considered more when making data visualizations

2022-09-22T00:00:00Z

Visual data representation is being used more and more in digital newsrooms across the world. The downside, however, is how exclusionary this can be for people with visual impairments.

It’s clear that visual journalism will play a huge part in the digital future for media outlets. From audience analytics tools measuring the impact of content, to representing complicated data in an easy to digest format, it’s easy to see the benefits of such tools and production techniques for creating impactful digital journalism.

It’s also clear that without a better understanding of how to make visual journalism work for everyone that huge parts of the audience are going to be left behind. In the UK alone, the Royal National Institute of Blind People estimate that around 2 million people are living with some sort of sight loss. Globally, the World Health Organization claim the number is close to 2.2 billion, with that number set to rise dramatically as people continue to age.

As a blind journalist, I’m concerned that the increased use of visual data representation without careful and creative thought about accessibility is widening the inaccessibility gap.

An example

During the COVID pandemic I wasn’t easily able to access COVID data represented on digital graphs, and I wasn’t alone. A project by MIT researching the problem of data visualization accessibility cited a simple chart from the beginning of the pandemic.

The cited chart demonstrated the benefits of mask wearing and social distancing for limiting the spread of the disease. The chart was amplified by many global media outlets, but was missed by millions of blind readers due to lack of meaningful text or audio description.

Data journalism’s access issues and greater potential

In my job as a digital journalist, I’m becoming increasingly aware of the desire to publish more and more impactful visual data journalism.

For a lot of people, visual representations of complicated data has the ability to translate data into a format our brains can comprehend easier and quicker. However, what’s not so obvious is how exclusionary that can be for those of us who don’t operate in a visual way.

I can’t take any of the other myriad of visual data tools and translate them quickly into a way my brain understands. This includes infographics, maps, pie and bar charts, etc.

As someone who uses a screen reader to translate what’s on my screen it’s imperative to have an alternative method of accessing whatever data I’m being presented with. For example, this could be through simple alternate descriptions in a bar chart or map.

I would also argue that this is fairly limiting and isn’t presenting the data in the creative and impactful way most visual data journalists strive for. What I’d like to see is more thought being given to developing creative alternatives for me and the millions of other people like me.

I would even go as far as arguing that visual data by its’ very nature is an accessibility tool. It’s taking complicated data and presenting it in a way which is easy for many people to understand. I want to see the same thought being given to people who absorb information differently.

I would also like to see thought and care being given to people who absorb information differently. Making visual data more widely accessible for neurodiverse people, or people with cognitive disabilities for example would also really help level a currently unlevel playing field.

My journey

In October of this year, I’m going to be starting a Fellowship with the prestigious Reuters Institute for the Study of Journalism at Oxford University. I’ll be working on how best to bridge this accessibility gap. It’s something I’m really passionate about, but it’s also something I know only from a user’s point of view.

I’m a journalist. I’m not a UX specialist or web developer in any way, shape or form. I care about making all forms of digital communication as accessible as possible. However, I’m acutely aware that being able to do this is outside my current skillset.

I’m a proficient screen reader user and can navigate the web reasonably well. Where my skillset is lacking is being able to design accessible user experiences for the increasing amount of visual data being produced.

I’m also aware that the need to know exactly how it all works isn’t entirely necessary. Before the widespread adoption of digital printing techniques, thousands of people were employed in the hot metal era of creating newspapers, and I would argue that not all journalists understood that world of printing. In the same way, there are designers and developers who can create the underlying design and code.

Collaboration

I’m really hoping by being able to work with these designers and developers, as well as with different people with many different skillsets who care as passionately as I do about universal accessibility and equitability for all. Together, we can move the dial on making more visual journalism accessible.

Global news organizations are rightly alert to the need for diversity and proper representation amongst their staff and the content they create. However, there’s a huge mismatch in this awareness and how data is being collated and presented in an equitable way for all parts of a global audience. I’m hoping by highlighting the issue I’ll be able to help efforts address this mismatch.

Please do get in touch if this sounds like something you’d like to know more about or can offer advice or help. I’m really hoping by pulling together we can all help to make a difference.

A guide to troublesome UI components

2023-02-14T00:00:00Z

A common opinion is that accessibility is expensive, and that if you think accessibility is expensive, you can deal with it later.

Here’s the twist: it will be expensive if you deal with it later. However, accessibility is not expensive if you discuss it as a team early in the process.

It is possible to build just about anything, it comes down to time and money. But no client ever has said, “Hey, we have a lot of time and money!” Accessibility is not expensive if you proactively plan for it. That’s why you need to learn how to avoid some of the common pitfalls.

Before we start

User interface (UI) elements are the parts we use to build apps or websites, such as links, accordions and checkboxes etc.

Some UI components are more complicated than other components. And some components are really complicated. All roles that build for the web (product owners, UX designers, art directors, developers, QA engineers) must know this.

The challenges

The components in this article all have the following challenges in common:

Keyboard interaction. Everything that can be done with a mouse, must be possible to do with a keyboard. This includes navigating, opening and closing items, activating, stopping, starting, selecting, etc.
Focus appearance and management. Users navigating by keyboard must know where they are. Always show the user’s current position in the interface. The focus order should be logical and intuitive.
Consistent announcements. All events and interactions should correspond as understandable and relevant audio feedback in screen readers. Buttons should describe themselves as buttons, links as links, etc.
Code quality. Using the correct elements and ARIA attributes, as well as valid HTML.

The components

Following are some UI components that have non-trivial considerations to use in an accessible way:

Custom selects

Native HTML <select> elements (sometimes referred to as dropdowns, not to be confused with disclosures) has the most understandable and usable experience across every platform compared to its custom-coded counterparts.

But here’s the thing: very often the design contains styling that will not work in a native HTML select element. Images of fruit (like in the illustration) cannot be added with HTML alone, we’ll need some trickery.

What can you style in a native HTML select?

Closed state (the <select>): Quite a lot.
Opened state (the <select>'s <option>s): Not much. Probably not the way you want to style it. No padding, no borders, no custom layout, no images of fruit.

The lack of styling support in the native HTML select is the number one reason why some developers will start building something that is completely custom.

Advice for a custom select

Don’t build a custom select. There is so much JavaScript you must write just to make it behave like a native HTML select.

Talk to the design team and see if you can change the design. If not, use a native HTML <select>. It will save you so much time, both in terms of building it and fixing bugs.

Please note: the options in a native select will have a slightly different look depending which browser and device you’re on. This is actually a positive, because the UI is looking consistent to the browser and OS.

Modals

A modal is the kind of UI that is layered on top over the page content. A common visual treatment for modals is a box in the middle of the viewport.

This is a pattern where the user is being interrupted in their workflow. A modal can help you focus your attention on a single task, in circumstances where complicated or data-heavy interactions are present. Here, the modal breaks you out of your flow state, which could be helpful when communicating critical information.

However, interrupting people for non-critical things like, “Signup for our newsletter” or, “Check out these new products” can be annoying. When this kind of modal is presented, the users have to expend extra effort—interacting with the dialog to dismiss it.

Modals are also referred to as “dialogs”. Is there a native HTML dialog element? Yes, there is <dialog>. Is it perfect? Not yet.

Historically, the developers had to write tons of Javascript to create modals. Support for the <dialog> element is improving. But you still have to write JavaScript. Make sure you test your <dialog> code with assistive technology before deploying it for general use.

Advice for modals

A dialog can be accessible, but be cautious. Be aware of the most common flaws:

The opened/closed state of the modal isn’t communicated to screen readers.
Not possible to close the modal with the Esc key on a keyboard when it is in its open state.
A modal's close button does not have accessible name that makes sense, such as using the letter “X” instead of the word “close”.
Missing keyboard focus trap, meaning you can use the keyboard to navigate the content behind the modal while it is in an open state.
Keyboard focus is not restored to the control that triggered the modal to open after the modal is closed.

Do consider if you can use alternatives to modals.

Autosuggest

People will say “autocomplete” but generally mean autosuggest.

Autocomplete comes out of the box with HTML. It will make suggestions based on values the user has previously entered and submitted in similar form fields, like names and email addresses. Very useful. Do use it, follow this excellent autocomplete guide from MDN.

Autosuggest, however, is different. It looks like an autocomplete by displaying a list of suggestions as the user types. But the suggestions are compiled from a data source, not the user’s previous entries.

The data source can be a known and static scope like countries and cities, or a wide and dynamic scope like saved overall website searches.

Is there a native HTML element? There is a datalist element, but it is not very well supported:

Advice for autosuggests

Be assured creating a custom autosuggest is a real undertaking, especially since you have an as-you-type situation on your hands. Again, there is so much JavaScript to write to make it work in a robust and predictable way.

The autosuggest UI is good for exploring, spelling and speed. But very few autosuggests are accessible. Their most common flaws are:

Navigation by keyboard is not coherent with established patterns.
Focus order is not logical and intuitive, especially entering the list.
No feedback to the screen reader what is going on.

I have seen how people struggle with this kind of UI. They failed to select the suggestion or thought the list of suggestions was the actual search result and didn’t press the search button.

There are a lot of details to get right for autosuggest experiences. User testing will reveal if it’s actually understood the way you intended.

Make sure that your model for building the suggestions themselves is rock-solid. If the suggestions are bad and not relevant—like showing suggestions for items you don’t have—it will hurt the search experience.

An easy-to-build and accessible alternative could be adding a list of popular links alongside the search input. If you save and tally user-enter searches in a database and use that for inspiration when compiling the list it can be helpful, even if it’s not dynamic or as-you-type.

Date pickers

A date picker is a form field widget which pops up a small calendar.

Is there a native HTML date input element? Yes. Is it perfectly accessible with full browser support? Far from it.

There are many known issues in the different browsers:

Should you then perhaps build a custom date picker? You know the answer to this one: no.

Advice for date pickers

There are many ways to input dates. A simple, effective way could be text inputs with date range validation, possibly combined with <select>s.

Sometimes, a date picker is actually the wrong UI to choose. Let’s say someone should input their date of birth. They would have to go backwards year by year, or even worse, month by month. That’s a lot of unnecessary interaction. If you think this is annoying, imagine how it is for someone with a motor control disability.

If you do decide to use a date picker, make sure the user can also input the date in ways other than the widget.

Carousels

A carousel (also known as a slider) is the concept of having content (images, headings, links, etc.) in a horizontal scroll. Usually there are some arrow buttons that will rotate the carousel content through. Some carousels rotate by autoplay, which is extremely distracting.

Is there a native HTML <carousel> element we can use? No.

Advice for carousels

Do not build a carousel.

As an accessibility auditor, I have yet to see a carousel that didn’t have multiple critical accessibility issues. Common issues include:

Cannot be operated with a keyboard.
Missing visible focus indicators.
Focus order is not logical and intuitive.
Arrow buttons do not have accessible names.
No feedback to screen readers.
No possibility to turn off autoplay.

Besides the technical challenges, you should also be aware that the conversion rate for carousels is low. Very few users actually read or engage with these things.

Stakeholders, designers or product owners may really press you to use a carousel, because they let everyone get their content onto a page. When reaching for a carousel, ask yourself: What are you really trying to accomplish, and is this the right component to accomplish that goal?

If you find yourself in a situation where you’re forced to build a carousel, make sure the issues outlined earlier are addressed, bare-minimum.

Dynamically-loaded content

Dynamically-loaded content is when you have more content inserted without requiring a page load. JavaScript code will send a request to a server, get some data, and that data will get injected into the page as new content without triggering a page load event.

Some typical scenarios are loading more search results, filtering search results, and giving confirmation after submitting a form.

This kind of UI is very common. Also very common is:

No feedback for screen readers that there is new content on the page.
Page focus order becoming illogical and unintuitive.

Advice for dynamically-loaded content

Dynamic content is not impossible to implement accessibility-wise. It just requires some extra work—same challenges here as the previous UI considerations.

An example: loading more search results. When activating a “Load more” button, additional search results will be fetched and inserted into the page.

The visual focus for these results should be placed on the first link in the new content. This will help someone using a screen reader understand new content is present.

Also, dynamically loaded content is missing out on features like a shareable URL and finding content via Cmd/Ctrl + F.

For better assistive technology support, URL sharing, ease of maintenance, and other concerns: consider regular page loading and pagination UI instead.

A note on npm packages

A npm package is someone else’s code you can use for free. Developers install npm packages to save time.

The npm registry contains packages for all of these previously mentioned components. Several packages claim to be accessible or WCAG compliant. But that’s just the author’s own opinion. Don’t take their word for it. Test and evaluate properly before committing.

The problem with importing third party code is you have limited to no control. Even if you know how to fix the problem, you can’t. The issues are embedded in the package, but you are still responsible. It is your decision to allow and use this package in the first place.

In order to correct a problem you’ve found, you'll have to:

Raise it with the package author,
Hope it gets dealt with,
If it does, then update the package, and then
Review every instance of the component to ensure the fix is working.

Quite a slow and agonizing process.

At the end of the day, people don’t care how stuff was built. Can they use the UI or not? That's all that matters.

Closing thoughts

Is accessibility expensive and difficult? If you have no experience or knowledge, it might seem that way.

Accessibility starts with giving a damn. Ask questions in forums, join communities, and listen to webinars.

Have accessibility top of mind. Discuss as a team before you start building. As a member of the team, speak up when you see a problem. Just ask, “Is this going to be accessible?” It’s really that simple.

Are you making these five mistakes when writing alt text?

2023-03-02T00:00:00Z

There are many benefits to writing alt text for images, especially from accessibility and legal standpoints.

But most don’t know how to write alt text well. I should know because, for an awful number of years, I was one.

I first learned about alt text in high school while building websites. But my proper lesson began when I took the Udacity Digital Marketing Nanodegree course, which was also my first introduction to marketing.

Screenshot from the SEO module of the Udacity Marketing Nanodegree course.

In this module, I learned about building easy navigation site structures, title tags, breadcrumbs, and meta descriptions—all the good stuff. We also learned about writing alt text and its importance.

Their overall advice? Describe what you see.

I thought that I finally understood it.

Sometimes it is simplicity that kills

When you ask them, most experts’ advice also boils down to: Describe what you see. And while it’s valid advice and may seem simple, it’s not.

Take the Udacity example earlier: Is this suitable alt text?

Source: Udacity Nanodegree Marketing Course.

If you close your eyes and someone reads out the words “eating apple heart disease” to you, does that in any way help you make sense of what’s in the image?

What about this example?

Source: Business Insider.

Does it?

The answer is a big no.

I used to just describe what I saw

Then two weeks ago, I watched Tommy Walker, an ex-Shopify senior content marketer and editor, critique an article for its alt text usage.

A snippet from The Cutting Room Show, hosted by Tom Walker.

Notice that the alt text does not communicate what the audit results are. Ironically, the article was arguing for accessibility. But it made the point clearer. And for the first time, it dawned on me that I’ve been writing alt text the wrong way.

This got me curious, so I started researching:

I read numerous UX and SEO blogs,
I spoke with practitioners in those fields, and
I chatted with some members of the low vision community.

Here’s what I learned and what I’m now applying to the articles I write:

1. Some images should use an empty alt attribute

First, to clarify:

An alt attribute is HTML syntax, and
Alt text is the description enclosed between the alt attribute's quotes.

All images need an alt attribute, but not all images need alt text. These are two different things, so do not mix them up.

So how do you know whether an image needs an empty alt attribute? The decorative/informative/active approach.

A short overview

Following is an overview of different types of images, and how to best describe them.

Decorative images

Decorative images' only value is aesthetic. If they are removed, the webpage would still make perfect sense.

Some examples are website banners that have no text in them and other design elements. You should omit the description for this type of image, but always include an empty alt attribute.

<!-- Sample decorative image -->
<img
  alt=""
  src="decorative-banner.png" />

Informative images

Informative images add extra context to the information presented in the article.

A few examples are graphs, diagrams, poll results, and product screenshots. Pay attention when describing them. You will learn how as you read on.

<!-- Sample informative image -->
<img
  alt="A small, black, compact digital camera."
  src="product-photo.png" />

Active images

Active images are used to perform actions such as signing up, downloading, listening, uploading etc.

They are mainly links and buttons. When writing alt text for these kinds of images, avoid terms like "Click here".

Instead, use descriptions like, "Sign up for a Twitter account", "Go to the account page", "Upload your national identity card", and so on.

<!-- Sample active image -->
<img
  alt="Upload resume."
  src="upload-prompt.png" />

2. Context matters

Alt text should concisely and accurately describe the image's content. If you have an overall point to make, let the surrounding text content communicate it.

For example, this image could be used for:

Helping to identify a business listing,
An exposé about an unscrupulous used car business,
A commercial real estate listing, or
A political campaign promising commercial revitalization.

It is up to the reader to decide how they feel about something, and alt text helps provide them the full context of the story.

This is useful not just for accessibility but also in competitive arenas like SEO where you’re competing with behemoths like HubSpot, Databox, The New York Times, and Zapier.

3. Screen readers and search engines already know that it’s an image

There’s no need to add in "image of", "picture of", or "graphic of". That only leads to repetition which can be annoying for listeners, particularly if the article contains a lot of images.

Instead, use the extra characters to convey information better.

Source: Zapier.

I love the simplicity of the next one:

This is nice.

4. Write alt text as simple sentences

A dark practice among search-engine optimizers is stuffing their target keywords into their images’ alt text. This is a terrible user experience.

The shocking reality?

Google’s John Muller has repeatedly said that alt attributes don’t affect normal Google search.

Besides that, if you think that you need to stuff your alt attributes with keywords, you’re starting on the wrong foot and Google is coming for you—just like it did for Overstock, BMW, and even Google Japan.

Screen readers like JAWS and NVDA read alt text aloud a lot like the way that we read sentences aloud. So you should format your descriptions as regular sentences with proper punctuation and spelling.

There is no one formula for how long alt text should be. You should concisely and accurately describe all important and relevant details present in the image.

In the cases where you need to describe a complicated graphic such as a chart or graph from a research study, consider following the W3C tutorial for dealing with complex images. Note that the longdesc method is no longer valid, however (reference the link's Notes section).

5. Don’t repeat captions in alt text

Copying captions verbatim into alt text is a popular practice in e-commerce because marketers think that that’ll help with their search-engine rankings, but that actually creates a bad user experience.

This is because screen readers end up repeating the same words. Imagine this happening for two, three, or even five images and you can quickly see how the experience goes downhill for people with disabilities.

Skip YouTube embed

Captions and alt text serve a different purpose. Captions are typically used to add details such as photo credit and copyright information. Alt text should describe the image’s meaning in the context of the article instead.

You can omit captions, but the same can’t be said for alt attributes.

Writing alt text might at first feel overwhelming or unproductive

For some, it may feel like you’re spending extra time and money on a small percentage of your user base and readers. So you may feel an urge to overlook alt text.

Setting aside exclusion and discrimination for a moment, this isn’t a risk you want to take on a company’s site. Because ignoring alt text is a recipe for disaster.

Target wished they had known earlier because it cost them $6 million in damages. When Netflix failed to take a cue from Target, it cost them $755,000 in legal fees and damages. The list goes on.

Even more, there’s a growing population of sighted people who use text-to-speech software so they can multitask or take a break from staring at LED screens all day long. Failing to make your content accessible will lead to a bad user experience.

It’s also a chance to get featured on the internet hall of fame

On some sites, a third of their traffic comes from Google Images. Doing alt text right is how Hubspot drove an extra 160,000 traffic sessions to their blog.

While it can feel like there’s much to learn just to make your website accessible, my advice is to not overwhelm yourself. Instead, take it step-by-step, and understand the basic purposes of alt text, which are:

Making it easier for screen readers to accurately describe images to the people who rely on them,
Appearing in place of the image if it fails to load, and
Helping search engines understand the graphics on your website.

Do you know what’s even better?

Hanging out in their communities,
Reading their rants and comments, and
Listening to a screen reader like NVDA and learning how exactly it works.

We can hypothesise as much as we want, but nothing beats walking a mile in readers’ shoes. You will learn more in an hour or two doing that than you will reading guide.

Appreciation

Credits to Cierra Loffins. She did most of the legwork for this article.

Getting started with TalkBack on Android

2023-03-06T00:00:00Z

Introduction to TalkBack

TalkBack is assistive technology that helps users with visual disabilities access native mobile applications and the web by providing audible and haptic responses to touchscreen gestures. It is the default screen reader software included on Google touchscreen devices running the Android operating system.

As of 2017, TalkBack is part of a family of software products in the Android Accessibility Suite including:

Accessibility Menu
Select to Speak
Switch Access

The Android Accessibility Suite comes pre-installed on devices running Android 9 or greater.

This article is an introduction to TalkBack version 13.1. We will walk you through the basics of enabling the software and navigating websites and applications with it.

Getting Started

There are three ways to activate Talkback:

From the settings menu: Accessibility > TalkBack > Toggle On
On the physical device: Press and hold both volume keys for three seconds
Via the Google Assistant: "Hey, Google. Turn on TalkBack"

Once TalkBack is on, it will begin speaking instructions to you. While there are more robust features to explore, the basic commands you should know are:

Tapping the screen selects an item, and
Double tapping the screen activates your selection.

TalkBack also makes use of single finger, two finger, and three finger gestures to perform additional actions.

There are at least three recognized ways to navigate with TalkBack: touch, swipe, and voice commands.

Navigating by touch

To navigate by touch, touch anywhere on the screen, selecting any element. It will be highlighted by a green border box similar to what you would find when using a keyboard to navigate a web page.

With pressure still applied, slowly drag your finger around the screen. As you move around the screen, TalkBack will jump to the next available item and announce its contents aloud. Once you've found the content you'd like to interact with, double-tap the screen.

Navigating by swiping

Navigating by swiping can provide a more precise experience. To navigate in this way, select an initial item by tapping on the screen. Then, with one finger, move left and right on the screen to move to the previous or next item.

Selected items will be read aloud by TalkBack in the order they appear. Double-tap the screen once you've found the content you'd like to interact with.

Swiping gestures may also be customized in TalkBack's preferences.

Navigating by voice command

In addition to touch controls, TalkBack supports some voice commands. To activate voice commands, using one finger, swipe down and right.

This gesture will open the TalkBack Menu. Select voice commands from the list to open a prompt with more information about specific commands you can use to navigate the page with just your voice.

Basic TalkBack Commands

Gesture	Description
Use one finger to tap your device's screen	Reads the selected item aloud
Use two fingers to tap your device's screen	Pauses the current reading
Double-tap your devices screen	Activates the selected item
Move two fingers up or down the screen	Scrolls up or down the content
Quickly flick up or down	Changes the read aloud speed
Use one finger to swipe down and right	Opens the TalkBack Menu

Wrapping up

You can start using TalkBack and your new skills right now! Get a feel for how these commands work in real life by navigating A11yProject.com with TalkBack turned on.

The power of ChatGPT as a cognitive accessibility assistive technology for Traumatic Brain Injury survivors

2023-03-14T00:00:00Z

This article was written by ChatGPT with the below prompt written by Jamie Vanderwall.

“Write about how ChatGPT can be used as a cognitive accessibility assistive technology specifically for traumatic brain injury survivors and how this impacts the disability community.”

Introduction

This essay explores the use of ChatGPT as a cognitive accessibility assistive technology for traumatic brain injury (TBI) survivors, discussing the impact it has on the disability community. The essay outlines the cognitive impairments experienced by TBI survivors, and how ChatGPT can provide support in the form of information retrieval, memory aids, communication aids, and cognitive training.

Traumatic brain injury (TBI) is a life-changing injury that can affect people of all ages, genders, and backgrounds. TBI can cause a range of physical, cognitive, and emotional impairments, making it difficult for people with TBI to perform daily activities, engage in social interactions, and access information. Cognitive accessibility assistive technology, such as ChatGPT, can help TBI survivors overcome some of the cognitive challenges they face and improve their quality of life. This essay will explore how ChatGPT can be used as a cognitive accessibility assistive technology specifically for TBI survivors and how it impacts the disability community.

What is ChatGPT?

ChatGPT is a large language model developed by OpenAI that can generate human-like responses to natural language queries. It is a type of artificial intelligence that uses deep learning algorithms to analyze and understand natural language input and generate a relevant and contextually appropriate response. ChatGPT can be used in various contexts, such as customer service, chatbots, and conversational agents.
How can ChatGPT be used as a cognitive accessibility assistive technology for TBI survivors?

TBI can cause a range of cognitive impairments, including memory loss, attention deficits, and difficulty with executive functioning. These impairments can make it challenging for TBI survivors to access information, communicate effectively, and perform daily tasks. ChatGPT can be used as a cognitive accessibility assistive technology for TBI survivors in several ways.

Information retrieval

TBI survivors may have difficulty retrieving information from memory, especially if it is complex or unfamiliar. ChatGPT can be used to help TBI survivors retrieve information by answering questions and providing relevant information. TBI survivors can ask ChatGPT questions about a topic they are interested in, and ChatGPT can provide a concise and clear response. ChatGPT can also provide visual aids such as images or videos to help TBI survivors understand the information better.

Memory aids

Memory loss is a common cognitive impairment among TBI survivors. ChatGPT can be used as a memory aid to help TBI survivors remember important information such as appointments, tasks, and medication schedules. TBI survivors can use ChatGPT to set reminders for important events or tasks, and ChatGPT can send them notifications when it is time to perform the task. ChatGPT can also provide verbal prompts to help TBI survivors remember important information.

Communication aids

TBI survivors may have difficulty communicating effectively, especially in social situations. ChatGPT can be used as a communication aid to help TBI survivors express themselves and understand others better. TBI survivors can use ChatGPT to practice social conversations, such as asking and answering questions, making small talk, and expressing emotions. ChatGPT can also provide feedback and suggestions to help TBI survivors improve their communication skills.

Cognitive training

TBI survivors may benefit from cognitive training to improve their cognitive abilities, such as memory, attention, and executive functioning. ChatGPT can be used as a cognitive training tool to provide TBI survivors with exercises and activities that target specific cognitive skills. For example, ChatGPT can provide memory games or attention exercises that TBI survivors can practice to improve their cognitive abilities.

How does ChatGPT impact the disability community?

The use of ChatGPT as a cognitive accessibility assistive technology for TBI survivors has several implications for the disability community.

Increased accessibility

ChatGPT can increase accessibility for TBI survivors by providing them with a tool that can help them overcome cognitive impairments. With ChatGPT, TBI survivors can access information, communicate effectively, and perform daily tasks more easily. This increased accessibility can help TBI survivors participate more fully in society and reduce the impact of their disability on their daily lives.

Reduced isolation

TBI survivors may experience social isolation due to their cognitive impairments, making it difficult for them to engage in social interactions. ChatGPT can help TBI survivors improve their communication skills and practice social conversations, which can increase their confidence and reduce social isolation. Additionally, ChatGPT can provide TBI survivors with access to online communities and social support groups, which can further reduce their sense of isolation.

Empowerment

ChatGPT can empower TBI survivors by giving them more control over their lives. With ChatGPT, TBI survivors can manage their schedules, set reminders, and access information more easily, reducing their dependence on others for assistance. This increased independence and control can boost TBI survivors’ self-esteem and improve their overall quality of life.

Technological advancements

The use of ChatGPT as a cognitive accessibility assistive technology for TBI survivors is a testament to the power of technological advancements in improving people with disabilities. As technology continues to evolve, there is potential for even more advanced and innovative assistive technologies to be developed, further enhancing the accessibility and quality of life for people with disabilities.

Conclusion

In conclusion, ChatGPT can be used as a cognitive accessibility assistive technology specifically for TBI survivors to help them overcome cognitive impairments and improve their quality of life. By providing TBI survivors with information retrieval, memory aids, communication aids, and cognitive training, ChatGPT can increase accessibility, reduce social isolation, empower TBI survivors, and demonstrate the power of technological advancements in improving the lives of people with disabilities. As technology continues to evolve, there is potential for even more advanced and innovative assistive technologies to be developed, further enhancing the accessibility and quality of life for people with disabilities.

What is Semantic HTML?

2023-04-04T00:00:00Z

A common refrain comes up often in the accessibility field. "Use semantic HTML," people say.

But what does that mean and why does it matter? More importantly, what do you get with semantic HTML?

What is Semantic HTML?

The word "semantic" has a few meanings. In computer science, semantics provides the rules for interpreting expressions of code. In this case, semantics lays out the rules for how HTML (the code) gets interpreted. Those rules govern structure and meaning.

Structure

HTML stands for Hypertext Markup Language. Invented by Tim Berners-Lee as a way to link together important research documents, HTML has evolved to do much more than that. Early versions had heading elements (h1, h2, etc.), but not the structural elements like <header>, <main> and <footer>. Those came later. Each of these elements gives structure to the document, the web page. Creating semantic code means picking the right element for the job, giving your page structure.

Meaning

The elements also have a meaning underneath. Every element has an implicit role. For example, the <header> element has the implicit role of "banner." That means that a screen reader will read that role as a landmark.

People who use screen readers can navigate by those landmarks, granting an easier way to skim the content of a page. If a developer used a <div> instead of a <header>, the implicit role would be absent, unless provided with extra code. That means the HTML won't be as useful to the machines that interpret it.

What you get with Semantic HTML

When you select the right element for the content you have, you get some things for free. Free as in the web platform gives it to you without any other effort. We talked about one already:

Structure and meaning gets conveyed to browsers and assistive technologies.
Some elements come with built in keyboard functionality, for example, the <form> element.
Other elements may communicate state to the browser and assistive technology. Radio buttons and checkboxes do this.
The browser will give you some CSS styles for free.
Search engines can index the content more efficiently so people can find it.
Technologies such as RSS readers and Reader mode can parse and style the content effectively.

If you use a <div> or <span> improperly in place of a more semantic element, you may have to recreate functionality. Worse yet, many people who rely on semantic HTML as the key underpinning of the web won't be able to use what you've made. Choose wisely.

Automated tools can ensure full accessibility compliance

2025-03-10T00:00:00Z

Can automated tools guarantee full compliance with accessibility standards like WCAG? The short answer is no. While automated accessibility tools are often marketed as comprehensive solutions, they are only part of the equation.

What automated tools can do

Automated tools are good at detecting straightforward accessibility issues, such as missing alt text, poor color contrast, and incorrect heading structures. Tools like WebYes and axe DevTools are examples of automated tools that efficiently flag these issues.

The speed and efficiency of automated accessibility tools make them ideal for initial audits. They can scan hundreds of web pages in minutes, pinpointing the most straightforward problems—what we often call “low-hanging fruit.”

The results of the initial audit provide a strong foundation, allowing teams to prioritize critical fixes and plan for deeper manual testing to address more complex accessibility issues.

What automated tools miss

While automated tools are excellent for identifying straightforward issues, they cannot evaluate issues that require human judgment, such as:

Whether alternative text for images is meaningful.
The logical flow and usability of keyboard navigation.
The clarity of instructions or error messages for forms.

When human judgment is missing, important accessibility issues can go unnoticed, making the experience difficult and frustrating for users with disabilities. This can prevent them from fully accessing or using the website as intended.

Studies highlight this gap. A Government Digital Service (GDS audit revealed that even the best automated tools detect only 30-40% of known accessibility issues. Accessibility expert Karl Groves notes that only 25 to 33% of WCAG guidelines can be reliably tested with automation.

Striking the right balance

The most effective approach combines automation with manual efforts. Automated scans identify technical issues, while manual reviews and usability tests uncover the subtle barriers tools miss.

By incorporating user feedback and providing your team with ongoing accessibility training, you can ensure compliance becomes an integral part of your development process—not just an afterthought.

Conclusion

Automated tools are essential for modern accessibility workflows, but they are not a complete solution. True compliance requires the precision of human judgment alongside the speed of automation. Together, they can create digital spaces that meet legal requirements and, more importantly, serve the diverse needs of all users.

The A11Y Project

Accessibility is 'blind people'

Four categories of accessibility

Visual

Associated conditions

Auditory

Associated conditions

Motor

Associated conditions

Cognitive

Associated conditions

Temporary disabilities

Navigate using just your keyboard

How to navigate a website with a keyboard

Things to keep in mind while testing

Using alt text properly

A few tips on how and when to use the alt attribute:

ARIA Landmark roles and HTML5 implicit mapping

Landmark quick reference

banner

search

main

navigation

contentinfo

HTML5 implicit mappings of Landmark roles

Getting started with macOS VoiceOver

Navigation modes

Grouping items

DOM Order

Reading text

The Web Item rotor

Never use maximum-scale='1.0'

About the maximum-scale attribute

The bad way

The good way

About the user-scalable attribute

Don't auto-play video, music and more

Sound

Vision

In HTML5

What if you can't say no?

Check contrast with your mobile device

Available tools

Future-proofing your accessibility efforts

Tech debt goes down when accessibility goes up

Breaking down the rules

4.1.1 Parsing

4.1.2 Name, role, value

Wrapping up

A primer to visual impairment

Who is at risk?

The causes

The challenges

The future is bright

Check comprehension level

Never remove CSS outlines

Use role='application'

Do

Don't

Hide content

Alternatives to display: none

People who use screen readers don't use JavaScript

Use title attributes

A primer to vestibular disorders

What is it?

Who is at risk?

What should you consider?

Use skip navigation links

Example

Notes

Using captions with HTML's video element

WebVTT

Other formats

Transcribing

Getting started with ARIA

ARIA attributes

ARIA roles

Landmark

Document Structure

Widget

A few tips on how and when to use the `alt` attribute:

Never use `maximum-scale='1.0'`

About the `maximum-scale` attribute

About the `user-scalable` attribute

Use `role='application'`

Alternatives to `display: none`

Use `title` attributes

`aria-labelledby`

Use `placeholder` attributes