I’ve added the six new WCAG 2.2 level A and AA success criteria (SC) to the “WCAG Success Criterion” column in each component’s tab. This brings the total number of SCs for an audit to 55. (4.1.1 Parsing is deprecated but still included for 2.1.) Each new SC is highlighted in light green and includes “NEW in 2.2” in its name.
If you’re not ready to test for WCAG 2.2 SCs, just mark them as N/A.
WCAG failure tracking
I’ve added rudimentary tracking of the number of WCAG violations found for each component which is displayed on the “Scope” tab in the a new “WCAG Violations” column. Each cell counts the number of “Fails” selected in the “Status” column of each component’s tab.
On the “Overview” tab, you can see a running total of all WCAG violations found for all components in the audit.
Prioritizing issues
I’ve also added a “Priority” column to each component’s tab. Each SC can be assigned a priority on a five-point scale:
Critical – Blockers that prevent someone from completing a task, e.g. a button that cannot be used with a keyboard
High – Issues that present a significant barrier to someone completing a task, e.g. application times out without allowing the user to extend it
Medium – (Most issues) Issues that present a barrier to some users from fully accessing the information or interface, e.g. text has poor color contrast
Low – Issues that present an unnecessary barrier but do not prevent a user from completing a task, e.g. image text that isn’t sufficiently descriptive
Best Practice – Issues that present some accessibility barriers but are not considered failures under the Web Content Accessibility Guidelines (WCAG), e.g. using a button instead of a link to open a webpage in a browser
If you have any questions about the spreadsheet or additions you’d like to see, please contact me.
I went to the movies this week for the first time since the pandemic began. I looked up showings at the Alamo Drafthouse and discovered little has improved with their payment process since I reviewed it on desktop back in 2016. This time, I completed the purchase on an iPhone using the responsive mobile website in the Firefox browser.
While I found several accessibility issues with the site, I’m highlighting concerns with the “Payment” screen. I’m neurodivergent and this post focuses on five things that cause me anxiety and make the experience frustrating:
I’ve done enough online ordering that I assumed that all the credit card-related fields are required, but many people will not understand that. E-commerce research suggests that marking all fields, required or optional, improves the customer experience. It certainly lessens my anxiety to know exactly which fields to complete.
Not only are required fields not clearly marked, but merely interacting with a field causes the display of an angry, red “Required” message. (This does not work for the “EXP” field even though it is required.) These input fields use a combination of the HTML required attribute with an aria-describedby attribute for the error message which causes assistive technology to announce fields are required multiple times.
Submit button is disabled
From the previous screenshots, we can see the next issue that causes me a lot of anxiety when using a website. The “Buy Tickets” button, which is the submit button for the form, is disabled by default. The button becomes enabled only after data has been entered into all the required form fields, which are not clearly marked.
There are two more required form fields below the credit card fields but they are easy to miss because of the sticky footer with the “Buy Tickets” button, meaning that after entering all credit card details, this button is still disabled.
Error messages don’t offer suggestions
The default error message for empty fields is “Required”. If a user enters data in the wrong format, the error messages change to “Invalid”. This doesn’t help the user in any way to figure out how to fix the error.
Here are some examples of helpful error messages:
Card Number: Please enter 16 digits
EXP: Please enter 2-digit year
CVV: Please enter 3 digits
Zip Code: Please enter 5-digit US zip code
“Zip Code” is the only field requesting numerical data that displays the numerical keyboard on mobile devices. Adding the inputmode="numeric" attribute to every field requesting numerical data will display the numerical keyboard too, which improves the accuracy of data entered into these fields.
Data formats are placeholder text
The requested data format for all the “Payment” screen fields are implemented as placeholder text. This means that once a person starts to enter data into the field, the required formatting of that data disappears. People are forced to recall from memory how to enter the data correctly. On top of this, the “EXP” and “CVV” fields allow someone to enter more digits than the data format allows.
The video below demonstrates what a person using assistive technology, like a screen reader, experiences when exploring the form. Notice how placeholder data are not consistently announced by VoiceOver.
Optional checkbox is already checked
Following the credit card-related fields is the “Email Confirmation” section which includes a checkbox that is already checked:
Join Alamo Victory
By checking “Join Alamo Victory” you start earning visits with this purchase for rewards and you agree to Alamo Drafthouse Cinema’s terms of use.
This is an optional field. It should require that I choose to check it. Because of its location behind the sticky footer, it’s very likely people will not see this checkbox and inadvertently join this program. Having to look for sneaky UI patterns like this makes for a bad experience.
Conclusion
This website has made some improvements like providing a “Back” button after timeout and inline form field validation. I also give the developers kudos for appropriately implementing the autocomplete attribute on the credit card-related fields. I’d make the following changes to the “Payment” screen to create a better experience for neurodivergent people:
Clearly indicate which form fields are required
Don’t disable the submit button
Offer suggestions for fixing data input errors
Display required data formats at all times
Don’t pre-check checkboxes for optional promotions
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.
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 video
Time spent watching
Live TV
23%
On demand video
77%
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
Year
US Consumers
2016
52%
2017
64%
2018
69%
2019
74%
2020
78%
2021
78%
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
Controls need to have an accessible name and an appropriate role.
Provide a visible focus indicator on interactive controls.
Ensure app works with multiple input modes: screen reader, remote, voice input, external keyboard.
Notifications should be announced to all users.
Control focus under actions.
Grouped controls needs a name.
Announce the number of items in a group.
Provide sufficient color contrast between the text and the background (image).
App should support zooming and resizing text.
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
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 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.
Rule
Status
1. Controls have accessible names/roles
Fail
2. Focus indicator on interactive controls
Pass
3. Support multiple input modes
Pass
4. Announce notifications
Fail
5. Focus management
Pass
6. Control groups have names
Fail
7. Groups announce number of items
Pass
8. Text color contrast
Fail
9. Support zooming/resizing text
Pass
10. Allow both screen orientations
N/A
Android phone
Screen reader: TalkBack on Android OS
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.
Rule
Status
1. Controls have accessible names/roles
Fail
2. Focus indicator on interactive controls
Pass
3. Support multiple input modes
Pass
4. Announce notifications
Pass
5. Focus management
Pass
6. Control groups have names
Fail
7. Groups announce number of items
Fail
8. Text color contrast
Fail
9. Support zooming/resizing text
Pass
10. Allow both screen orientations
Fail
Fire TV
Screen reader: VoiceView on Fire OS
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.
Rule
Status
1. Controls have accessible names/roles
Fail
2. Focus indicator on interactive controls
Pass
3. Support multiple input modes
Pass
4. Announce notifications
Pass
5. Focus management
Pass
6. Control groups have names
Pass
7. Groups announce number of items
Fail
8. Text color contrast
Fail
9. Support zooming/resizing text
Pass
10. Allow both screen orientations
N/A
Samsung TV
Screen reader: Voice Guide on Tizen
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.
Rule
Status
1. Controls have accessible names/roles
Pass
2. Focus indicator on interactive controls
Pass
3. Support multiple input modes
Pass
4. Announce notifications
Pass
5. Focus management
Pass
6. Control groups have names
Pass
7. Groups announce number of items
Pass
8. Text color contrast
Fail
9. Support zooming/resizing text
Fail
10. Allow both screen orientations
N/A
Xbox
Screen reader: Narrator on Xbox software system
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.
Rule
Status
1. Controls have accessible names/roles
Pass
2. Focus indicator on interactive controls
Pass
3. Support multiple input modes
Pass
4. Announce notifications
Fail
5. Focus management
Pass
6. Control groups have names
Pass
7. Groups announce number of items
Pass
8. Text color contrast
Fail
9. Support zooming/resizing text
Pass
10. Allow both screen orientations
N/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.
Rule
Apple TV
Android
Fire TV
Samsung
Xbox
1. Controls have accessible names/roles
Fail
Fail
Fail
Pass
Pass
2. Focus indicator on interactive controls
Pass
Pass
Pass
Pass
Pass
3. Support multiple input modes
Pass
Pass
Pass
Pass
Pass
4. Announce notifications
Fail
Pass
Pass
Pass
Fail
5. Focus management
Pass
Pass
Pass
Pass
Pass
6. Control groups have names
Fail
Fail
Pass
Pass
Pass
7. Groups announce number of items
Pass
Fail
Fail
Pass
Pass
8. Text color contrast
Fail
Fail
Fail
Fail
Fail
9. Support zooming/resizing text
Pass
Pass
Pass
Fail
Pass
10. Allow both screen orientations
N/A
Fail
N/A
N/A
N/A
Conclusion
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.
