The web is inherently accessible

Originally posted 7 February 2021. Updated 13 April 2022.

It all started when I built the Accessible Web tool which removes CSS and JS from a webpage, leaving plain HTML. I built it as a sarcastic response to a developer who changed his website to require visitors to disable JavaScript before they could view the content. The reactions to this gatekeeping on Twitter were hilarious! So many angry developers didn’t get the joke that they put up similar barriers when they require that people have JavaScript enabled to view anything on their websites.

I created an About page for the project that requires the user to disable CSS to view a message about web accessibility and the importance of semantic markup. The following is a blog article version of that webpage with code examples.

Accessible Web - please disable CSS to view this website

The web is inherently accessible

Your weekly reminder that the web is accessible by default and it’s our design decisions that stop it being accessible #a11y

k.mar (@Kevmarmol_CT) on Twitter December 7, 2020

Why did you have to disable CSS to view this webpage? No reason other than a design choice that excludes sighted people.

Did you know? This is how many visitors “view” webpages already:

  • Search engines
  • Bots
  • Site crawlers
  • Analytics
  • Blind people

This webpage is fully accessible to people with screen readers and Braille displays. But many websites are not due to poor design choices that exclude some people.

What is web accessibility?

When a page is accessible, it was developed with the intention of working for as many people with disabilities as possible. A good place to start learning is the W3C’s Introduction to Web Accessibility. Find out the different ways people with disabilities interact with the web.

Web Content Accessibility Guidelines (WCAG)

WCAG is a set of success criteria for determining if a page is accessible, led by four guiding principles:

  • Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
  • Operable: User interface components and navigation must be operable.
  • Understandable: Information and the operation of the user interface must be understandable.
  • Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

These contain guidelines and a hierarchy of success criteria from Level A to Level AAA. Many accessibility laws, and current best practice, point to WCAG 2.1 Level AA compliance. There are 50 discrete success criteria to evaluate, though many are not applicable to all pages. For example, if a page doesn’t contain video, you don’t have to evaluate against success criteria for captions or audio descriptions.

See the full list of success criteria

Did you know? The WCAG guidelines were first published in 1999. Web accessibility is not a new concept but a lot of people are learning about it only now.


So what’s the point? The point is to develop accessible pages from the bottom up, starting with semantic HTML. A whole lot of developers think they know HTML but are actually pretty sloppy about it. Many don’t think it matters if they use a link or a button, but it does. Every semantic mistake introduces accessibility issues into your code. If you’ve never really “learned” HTML, check out this beginner’s guide to writing good HTML.

By far, CSS color contrast issues are the most frequent accessibility issues I encounter, but the HTML ones are problematic too. Outlined below are the top HTML-related accessibility issues I encounter.


If you visually scan this page, you can quickly see how it is broken up into sections. That’s due to using headings or the h1-h6 elements. It’s important that every page have at least one h1 so people and search engines know what the topic of the page is. From there, cascade down to h2, h3, and so on.

Did you know? People using screen readers can navigate by headings in much the same way that sighted people can visually scan the page for items of importance.

Buttons and links

Buttons and links may seem similar but they have very different semantic uses. If you use them interchangeably, people can get confused about what a button or link is going to do when activated.


Buttons are used for controlling actions on the page, such as a form submit button or toggle button.

It’s preferable to use a native button element instead of creating a custom one:

  • It already has the button role
  • It’s keyboard focusable
  • It’s activated with ENTER and SPACE keys

The button element can have various states depending on its purpose:


<button aria-expanded="false">Menu</button>


<button aria-expanded="true">Search</button>

Not pressed

<button aria-pressed="false">Light mode</button>


<button aria-pressed="true">Dark mode</button>


Links are used for navigation, literally for linking to another page or place on the same page. When you use a link, people expect to go somewhere new when it’s activated.

It’s important that the link text properly convey the link purpose. Avoid generic text like “click here”.

Same page link

<a href="#headings">Headings</a>

New page link

<a href="/site-map/">Site map</a>

External link

<a href="">EFF</a>

Email link

<a href=""></a>


The one thing about accessibility most people know is that images need alt text. This may seem straightforward but let’s look at three examples.

1) Alt text

Semantically speaking, every image needs an alt="" attribute. This alone will pass an automated accessibility checker. If an image is purely decorative, you can even leave the alt value empty. But if an image provides context to the content, the alt text must accurately describe the content of the image for people who cannot see it.

<img src="cats.jpg" alt="two cats on an easy chair under a blanket">
two cats on an easy chair under a blanket

2) SVG

Inline SVG doesn’t support the alt attribute. Instead, add role="img" to the svg element to identify it as an image. Give it an accessible name using the aria-label attribute on the svg.

<svg role="img" aria-label="Bar chart showing the years 2016 to 2021 as the percentage of US consumers with a streaming video service increased from 52% to 78%." xmlns:xlink="" version="1.1" xmlns="" viewBox="0 0 650 400">...</svg>
US Consumers 52% 64% 69% 74% 78% 78% 2016 2017 2018 2019 2020 2021 0 20% 40% 60% 80% 100%

Go to the Tables section for information on providing access to all data points in the graph.

3) Icons

Any time you display icons that convey meaning to the user, you must provide a text equivalent for users of assistive technology. For example, it’s common to insert an external link icon after link text that opens in a new tab or window.

Icon fonts are not announced reliably by assistive technology. First, hide the icon using the aria-hidden attribute. Then provide a text equivalent with visually-hidden text.

Exposed icon

☎ 1-800-799-SAFE

<a href="tel:1-800-799-7233">☎ 1-800-799-SAFE</a>

Hidden icon

Call 1-800-799-SAFE

<p><a href="tel:1-800-799-7233"><span class="visually-hidden">Call</span><span aria-hidden="true">☎</span> 1-800-799-SAFE</a></p>


There are many legitimate uses for tables on the web but they are often coded incorrectly. Table data cells need corresponding table headers. This allows the applicable table header to be read by a screen reader before the table data cell contents. Additionally, tables need captions to provide a description of the table to people using screen readers.

In the SVG example under Images, we looked at a svg bar chart where we provided a snapshot of the data using aria-label. We need to provide all the data in a format that assistive technology can navigate and an easy way to do that is to provide all data points in a table.

US consumers with a streaming video subscription
Year US Consumers
2016 52%
2017 64%
2018 69%
2019 74%
2020 78%
2021 78%
  <caption>US consumers with a streaming video subscription</caption>
      <th>US Consumers</th>


Every input needs a label. It’s really that simple. The label needs to be visible and persistent (avoid using placeholder). This helps people remember what information they’ve entered. Programmatically link each pair matching the for attribute on the label with the id attribute on the input.

This enables a couple things:

  • People can now click or tap on the label to give focus to the input. This is especially useful for checkboxes and radio buttons that often have small hit areas.
  • People using screen readers will now hear the label announced when the input is in focus.

When you have a group of related form fields, like checkboxes or radio buttons, group them with a fieldset element and provide an accessible name for the group with a legend element.

  <legend>Cat's Colors</legend>
  <p><label for="black"><input type="checkbox" id="black"> Black</label></p>
  <p><label for="white"><input type="checkbox" id="white"> White</label></p>
  <p><label for="brown-tabby"><input type="checkbox" id="brown-tabby"> Brown tabby</label></p>
  <p><label for="orange-tabby"><input type="checkbox" id="orange-tabby"> Orange tabby</label></p>
  <p><label for="torbie"><input type="checkbox" id="torbie"> Torbie</label></p>
  <p><label for="gray"><input type="checkbox" id="gray"> Gray</label></p>

Many modern browsers do cursory form field validation with the required attribute though error messages are not always accessible. Let assistive technology users know when a field is required by adding the aria-required="true" attribute to inputs.

<label for="email">Email<span aria-hidden="true"> *</span></label>
<input type="email" id="email" autocomplete="email" name="email" aria-required="true">

For a deeper dive into forms, check out my blog article and talk Structuring accessible forms.

In summary

  • Web accessibility is an ongoing process
  • Use semantic markup: Native HTML + ARIA
  • Headings help people navigate
  • Buttons and links do different things
  • Images need text equivalents
  • Use tables for data
  • Structure forms in accessible ways

Making streaming video inclusive

Updated: 9 May 2022 for AccessU

This blog article supplements the talk Making Streaming Video Inclusive, created with my colleagues Carolina Crespo and Charu Pandhi of TPGi and delivered at CSUN 2022 and AccessU 2022. The idea for this talk came from an extensive client audit we participated in: Testing a streaming video application across multiple platforms and devices. With what we have learned, we aim to contribute to best practices for creating inclusive streaming video experiences.

Who's watching? screen with five profiles
Select a profile screen

The state of steaming video

As of February 2022, 77% of global viewing time for video is spent watching on demand content: source.

Global viewing time for video
Type of videoTime spent watching
Live TV23%
On demand video77%
Pie chart showing people watch on demand content 77% of the time and live content 23% Live TV: 23.0 % On demand video: 77.0 %

In 2021, 78% of US consumers had a video on demand subscription. That’s a 50% increase in the number of subscribers over the last six years: source.

US consumers with a streaming video subscription
YearUS Consumers
Bar chart showing the years 2016 to 2021 as the percentage of US consumers with a streaming video service increased from 52% to 78% US Consumers 52% 64% 69% 74% 78% 78% 2016 2017 2018 2019 2020 2021 0 20% 40% 60% 80% 100%

Demand for streaming video services is not only growing, it’s here to stay as more and more providers enter the market each day. But how accessible is this flood of new apps?

Case study: discovery+

Our team had the opportunity to test the discovery+ streaming video app across multiple devices to explore the differences in implementation and the support for assistive technology built into the platforms.

We used the Web Content Accessibility Guidelines (WCAG) version 2.1 AA success criteria as guideposts for our review since separate guidelines for mobile accessibility are not yet available. Based on what we encountered during accessibility testing, we comprised a list of the top 10 accessibility concerns focused on the application UI—issues that impede disabled people from completing common user journeys:

  • Sign in
  • Explore what is available
  • Select a show to watch
  • Add and remove shows to/from My List
  • Start watching

Top 10 app UI accessibility concerns

  1. Controls need to have an accessible name and an appropriate role.
  2. Provide a visible focus indicator on interactive controls.
  3. Ensure app works with multiple input modes: screen reader, remote, voice input, external keyboard.
  4. Notifications should be announced to all users.
  5. Control focus under actions.
  6. Grouped controls needs a name.
  7. Announce the number of items in a group.
  8. Provide sufficient color contrast between the text and the background (image). 
  9. App should support zooming and resizing text.
  10. Do not restrict the device to only one orientation.

Accessible content

While our research focused on the functional accessibility of the app, an app is only as accessible as the content it provides. You can have the most intuitive, well-designed interface for finding streaming video content but fail to provide appropriate alternative content for disabled users. Let’s look at three content-related considerations.


Captions are required on streaming content in the US by the 21st Century Communications and Video Accessibility Act of 2010 and other laws. Streaming companies like Netflix went through litigation for not providing captions. All video content we encountered on the discovery+ app had closed captions and controls for turning them on or off.

While captions are now standard and expected by consumers, they are not all the same. Captions must be of high quality and accurate to be useful and provide an accessible experience. Autocaptions that are not reviewed and edited are rarely good enough on their own.

We should also consider other user needs for accessible captions and ways we can enable users to control their captioning experience. Consider providing caption settings where users can control the color, font, size and position of captions and subtitles.

Audio description

Audio description is a separate audio track for video content that describes what is occurring on screen including text overlays and important actions. Like captions, users need accessible controls for enabling the audio description track.

None of the videos we encountered on the discovery+ app had audio descriptions, which is not uncommon but does exclude users who are blind or low vision. Companies are now engaged in legal action over audio description including a settlement between the American Council of the Blind (ACB) and Hulu; and structured negotiations between ACB and Netflix as well as ACB and WarnerMedia (HBO Max).

ACB runs the Audio Description Project that has a searchable database of audio described titles by streaming service.

Voice input

Voice input is a means of controlling the application with voice commands. Only two of the devices we tested support voice input and neither was capable of fully controlling the discovery+ app. This is due to a mix of what the platform supports and what the application supports. To the extent available, we recommend implementing voice support in streaming video applications. Voice input aids in navigating the application as well as making on-screen data entry easier, such as a natural language query to search for content.

Accessibility testing

We included five devices and platforms in this review:

Apple TV

Screen reader: VoiceOver on iOS

A small, square Apple TV console next to an Apple TV remote with a track pad and an Bluetooth keyboard.
Apple TV console, remote with track pad and Bluetooth keyboard

Apple TV findings
  • Profile buttons do not have accessible names or roles that distinguish them.
  • Notifications when a show is added or removed to or from a list are not announced.
  • Carousels lack names.
1. Controls have accessible names/rolesFail
2. Focus indicator on interactive controlsPass
3. Support multiple input modesPass
4. Announce notificationsFail
5. Focus managementPass
6. Control groups have namesFail
7. Groups announce number of itemsPass
8. Text color contrastFail
9. Support zooming/resizing textPass
10. Allow both screen orientationsN/A

Android phone

Screen reader: TalkBack on Android OS

A smartphone next to a Bluetooth keyboard
Samsung Galaxy S20 and a Bluetooth keyboard
Android findings
  • “Add to My List” and “Remove from My List” controls are missing the button role and accessible names.
  • Episode selector does not announce the number of items in the control, the button role or selected state.
  • Most player controls do not have proper accessible names and roles.
1. Controls have accessible names/rolesFail
2. Focus indicator on interactive controlsPass
3. Support multiple input modesPass
4. Announce notificationsPass
5. Focus managementPass
6. Control groups have namesFail
7. Groups announce number of itemsFail
8. Text color contrastFail
9. Support zooming/resizing textPass
10. Allow both screen orientationsFail

Fire TV

Screen reader: VoiceView on Fire OS

Fire TV stick and remote next to a Bluetooth keyboard
Fire TV stick and remote with a Bluetooth keyboard

Fire TV findings
  • Profile buttons do not have accessible names that distinguish them.
  • Tabbed navigation and carousels do not announce the number of items in the group. Episodes announce n of -1.
  • Shows do not announce their titles which are displayed as images.
1. Controls have accessible names/rolesFail
2. Focus indicator on interactive controlsPass
3. Support multiple input modesPass
4. Announce notificationsPass
5. Focus managementPass
6. Control groups have namesPass
7. Groups announce number of itemsFail
8. Text color contrastFail
9. Support zooming/resizing textPass
10. Allow both screen orientationsN/A

Samsung TV

Screen reader: Voice Guide on Tizen

Samsung 42" TV and remote next to a Bluetooth keyboard
Samsung TV and remote with a Bluetooth keyboard

Samsung TV findings
  • Sign In form does not provide audible feedback for input typed with a Bluetooth keyboard.
  • Low color contrast between text and background images.
  • Episodes don’t announce the episode number.
1. Controls have accessible names/rolesPass
2. Focus indicator on interactive controlsPass
3. Support multiple input modesPass
4. Announce notificationsPass
5. Focus managementPass
6. Control groups have namesPass
7. Groups announce number of itemsPass
8. Text color contrastFail
9. Support zooming/resizing textFail
10. Allow both screen orientationsN/A


Screen reader: Narrator on Xbox software system

White Xbox console and controller
Xbox console and controller

Xbox findings
  • Content is grouped, group label is announced, Tabbed navigation announces the number of items in the group, for example 3 of 10.
  • Visual notifications are not announced.
  • Regular text does not have sufficient contrast with its background.
1. Controls have accessible names/rolesPass
2. Focus indicator on interactive controlsPass
3. Support multiple input modesPass
4. Announce notificationsFail
5. Focus managementPass
6. Control groups have namesPass
7. Groups announce number of itemsPass
8. Text color contrastFail
9. Support zooming/resizing textPass
10. Allow both screen orientationsN/A

Overall findings

Every platform tested had issues, with Samsung TV and Xbox having the most accessibility support and Apple TV and Android having the least.

RuleApple TVAndroidFire TVSamsungXbox
1. Controls have accessible names/rolesFailFailFailPassPass
2. Focus indicator on interactive controlsPassPassPassPassPass
3. Support multiple input modesPassPassPassPassPass
4. Announce notificationsFailPassPassPassFail
5. Focus managementPassPassPassPassPass
6. Control groups have namesFailFailPassPassPass
7. Groups announce number of itemsPassFailFailPassPass
8. Text color contrast FailFailFailFailFail
9. Support zooming/resizing textPassPassPassFailPass
10. Allow both screen orientationsN/AFailN/AN/AN/A


This article represents data for a single app only and we encourage the community to research other applications across additional platforms and devices to add to the body of knowledge. Our goal was to surface specific accessibility issues that have a critical impact on a user’s ability to navigate the journey from signing in to watching a show. We hope this creates visibility and awareness of the effects from not testing for, and fixing, accessibility issues in streaming video applications and helps inform the pool of best practices for inclusive streaming experiences.

Structuring accessible forms

On 28 September 2021, I was a guest on Ben Myer’s Twitch stream where we demonstrated best practices for structuring accessible forms. Following is the example code and an explanation of what we covered.

See the Pen Accessible Forms by Rachele (@racheleditullio) on CodePen.

Creating our form fields

The two basic parts of a form field are its <label> and <input> elements. We semantically link the two by

  • Using the <label for="uniqueID"> attribute which matches the <input id="uniqueID"> attribute; or
  • Making the <input> element a child of the <label> element

Doing so allows screens readers to announce the field’s <label> when the <input> gets focus. It also enables the <label> as an additional hit area when using the mouse to focus on an <input>, which is especially useful for checkboxes and radio buttons.

We also need to specify the type of input using the <input type=""> attribute. Putting those together, we have a basic form with one text field and two radio buttons.

  <label for="name">Cat's name</label>
  <input type="text" id="name" name="name">

  <label><input type="radio" id="yes"> Yes</label>
  <label><input type="radio" id="no"> No</label>

  <button type="submit">Send</button>

A note on combo boxes

As much as possible, use native HTML <select> and <option> elements to create an expandable list of single-select options.

<label for="markings">Cat's markings</label>
<select name="markings" id="markings">
  <option value=""> select an option </option>
  <option value="solid">Solid</option>
  <option value="bi">Bi-color</option>

Grouping similar fields

Our radio buttons are labeled ‘yes’ and ‘no,’ but what are they for? We need to use the <fieldset> and <legend> elements to provide that semantic meaning. The <fieldset> groups the related form fields while the <legend> provides a name for the grouping. These are most often used for checkboxes and radio buttons but they can be useful for grouping other related fields, e.g. Shipping address.

Since radio button options may have similar names, group like radio buttons with the name="groupName" attribute. Keyboard users move between radio buttons in a group with the arrow keys.

  <legend>Is your cat altered?</legend>
    <label><input type="radio" name="altered" id="yes"> Yes</label>
    <label><input type="radio" name="altered" id="no"> No</label>

Marking required fields

Let’s create a required field for collecting email address with <input type="email">. Provide a visible indication of the required field for sighted users, such as an asterisk, but hide it from assistive technology using the aria-hidden="true" attribute.

Then there are two attributes we can use to programmatically define required fields: aria-required="true" and required.

Use one (not both) of these attributes to ensure required fields are conveyed appropriately to assistive technology. Screen readers will say required when announcing the form field name, role and state.

<label for="email">Your email<span aria-hidden="true">*</span></label>
<input type="email" id="email" name="email" aria-required="true">

The required attribute provides a first layer of form validation on submit. Many modern browsers will not submit a form with empty required fields and will even provide a visible error message.

a requried field in a web form that is empty and displays the message please fill out this form field.
Required field in Firefox for Windows

However, user agent error handling is not dependable as these error messages are not always announced or available to assistive technology; they can’t be styled or resized; and they are not persistent.

Handling errors

It’s important to provide a list of all errors at the top of the form or provide them in-context of the field in error. We can programmatically link the error message with the form field using the aria-describedby attribute.

<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email">
<p id="error-email">Email format</p>

When assistive technology users focus on the email field, the error message is announced along with the name, role and state of the field.

Verifying data

In addition to marking fields as required for assistive technology, we also have to indicate if the data entered into each field is valid. All required fields should also include the aria-invalid="true" attribute. Update this to “false” when it passes validation.

It’s also an accessibility requirement to make entering valid data as easy as possible. HTML has a set of autocomplete values that we need to use for any fields collecting personal information that might already be stored in the user’s browser. Email is one of these fields.

<input type="email" id="email" name="email" aria-required="true" aria-describedby="error-email" aria-invalid="true" autocomplete="email">

We can further enforce data validation in HTML for fields that aren’t necessarily required by using the pattern attribute that accepts a regular expression. Let’s create a field for collecting birthday with a required format of mm/dd/yyyy.

<input type="text" id="birthday" name="birthday" aria-describedby="help1" pattern="^\s*(1[012]|0?[1-9])\/(3[01]|[12][0-9]|0?[1-9])\/((?:19|20)\d{2})\s*$">
<p id="help1">Birthday format mm/dd/yyyy</p>

This pattern matching prevents the form from submitting if the data entered does not match the specified pattern.


I hope you found something to make your forms more accessible. I like forms because they have such a strong semantic structure. There are a lot of things to get right but it’s pretty straightforward what “right” means in this context: Make sure anything that is conveyed visually is also conveyed to assistive technology, including the states of form fields.