Perceivable
Guideline 1.1 Text alternatives
Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols, or simpler language.
What should the tester do?
Make sure all non-decorative elements on the screen have proper accessibility labels that can be read by VoiceOver/Talkback.
How?
There are several ways this can be tested. The first and most obvious one is to turn on the VoiceOver/TalkBack feature and go through all elements on the screen and ensure that the screen reader reads them properly. Labels should be clear, concise, and unique.
There are some tips and tricks to make this process faster and easier:
Android – use the Accessibility scanner – it will recognize all unlabeled elements. Keep in mind that the Accessibility scanner will only recognize missing labels, not the ones that are wrong or vague. You would still want to check them all with VoiceOver/TalkBack.
iOS – use the Accessibility inspector in XCode to find missing labels. One great tip for testing labels is to use Voice Control – turn it on, and say “Show names”. You’ll see the accessibility labels of your actionable elements on the screen. Find more useful tips on how to test iOS accessibility here.
What to report?
Any missing labels Labels that are not correct, not unique, or are vague Labels that are not localized If the element is purely decorative, it’s fine if it doesn’t have any label.
Guideline 1.2 Captions
Provide alternatives for time-based media.
What should the tester do?
Make sure that all media content is accessible to everyone. For example, suppose we have audio-only content in our app. In that case, we should offer captions for users with hearing impairments, or if the content is video-only, we should offer a suitable transcription.
How?
Simply check the media in your app and ensure they have suitable alternatives for differently-abled people.
What to report?
Any missing content that would make the media in the app inaccessible to some users (no closed captions for videos, no transcription for audio-only).
Guideline 1.3 Adaptable
Create content that can be presented differently (for example, a simpler layout) without losing information or structure.
This guideline has a few (fairly different) success criteria, and we need to test against all of them. To make it easier, we will explain each of them separately.
Success Criterion 1.3.1 Info and Relationships
What should the tester do?
Make sure that elements on the screen are grouped in a meaningful way. It’s important for all information and relationships perceivable to one set of users to be perceivable to all.
Here is a quote from WCAG explaining it so that it will be more clear:
“Sighted users perceive structure and relationships through various visual cues — headings are often in a larger, bold font separated from paragraphs by blank lines; list items are preceded by a bullet and perhaps indented; paragraphs are separated by a blank line; items that share a common characteristic are organized into tabular rows and columns; form fields may be positioned as groups that share text labels; a different background color may be used to indicate that several items are related to each other; words that have special status are indicated by changing the font family and/or bolding, italicizing, or underlining them; items that share a common characteristic are organized into a table where the relationship of cells sharing the same row or column and the relationship of each cell to its row and/or column header are necessary for understanding; and so on. Having these structures and these relationships programmatically determined or available in text ensures that information important for comprehension will be perceivable to all.”
This might sound rather vague, so let’s try a few examples. For example, if we have a checkbox with a label next to it, it will be clear what needs to be done here to a sighted user. But for a user that is using a screen reader, it might not be – e.g. if everything is not set up properly, a screen reader might read the element before, then read a checkbox, then read the description – this way, the user will not know:
- whether the checkbox is related to the first or the second element
- what is the status of the checkbox and if they tap on it they might
- when the status changes
Similarly, this can also apply to lists, headers in the app, tables, and so on.
How?
By using a screen reader and/or switch access. When navigating through a screen, the tester should ensure that elements are grouped logically and that the user using a screen reader can get the same set of important information on the relationship between elements as a sighted user.
What to report?
Report checkboxes/radio buttons that are hard to use with screen readers; tables that are not providing clear information (as they do for sighted users); numbered lists where the number isn’t connected with the item on the list and any other relationship that might be confusing and not communicated to a user using a screen reader.
Success Criterion 1.3.2 Meaningful Sequence
What should the tester do?
According to WCAG, the sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. When the sequence is meaningful, the tester needs to make certain that the user can perceive the information in the right sequence no matter how they perceive it (via a screen reader or without it, with switch access or without it).
It means that the title of the text should be read before the text itself and that the text’s title should be related to the text below. If we have ordered a list, it will be shown/read/navigated through in the right order, and if we have a table view, it will also be navigated/read in the right and meaningful order.
Similarly, it includes things like: the label of the element will be read together with that exact element, the navigation through multiple elements with the label will be done in a way “element-label, element-label, element-label” and not “element-element-element, label-label-label”.
How?
To test this criterion, it is best to use a screen reader (VoiceOver or TalkBack) and Switch access/Switch control settings. Of course, some breaches of meaningful sequence can be spotted with the bare usage of the app (e.g. if an article has a wrong title), but screen readers and switch control tools will help discover most of the issues.
What to report?
Breaches of this criterion mostly look like this: ordered lists are not marked as such, but as plain text, table views are not read (or navigated through, if you’re using Switch access/control) in the right sequence, headers are not marked as headers and similar. Wherever the sequence of reading the screen/navigating through it might confuse a user, report it and propose a better solution.
Success Criterion 1.3.3 Sensory Characteristics
What should the tester do?
You should check that instructions for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.
How?
This one can be tested through regular manual testing – navigate through the app and make sure that nowhere in the app is important information communicated solely with the sensory explanation.
If you want to be more thorough, you can try using the app in grayscale (you can change it in the display settings of your device) and with a screen reader, but if you know what you’re looking for, regular exploratory testing should be enough.
What to report?
If important information is communicated through:
- color only (you can see it often on graphs, ON/OFF indicators, and similar)
- orientation only (“to continue, tap on the button below/to your left”)
- sound only (“wait until the sound signal to continue”)
- shape/size (“tap on the big button/round button”)
- and similar
Success Criterion 1.3.4 Orientation
What should the tester do?
Two things: make sure that the app can change the orientation (unless a specific display orientation is essential) and that the app doesn’t lose any functionality when the orientation changes.
How?
Change the orientation of your phone from portrait to landscape and vice versa, and see how the app will behave (check if your phone is locked to a single orientation). If the app changes orientation, do a sanity check of at least the most important functionalities and ensure they work as they should. Watch out for loss of important information, broken or lost buttons, non-responsive input fields, and similar.
What to report?
- If the app doesn’t change its orientation. Fixing this one might be a business decision – here is some clarity on what “essential” means.
- If some of the app's functionality is lost after it changes orientation.
Success Criterion 1.3.5 Identify Input Purpose
What should the tester do?
Ensure that every input field has a clearly stated label, that VoiceOver and TalkBack recognize it as an input field, and that an appropriate keyboard is opened when the user taps on it.
How?
Open the app and navigate to the place in the app where there are some input fields. Make sure that every field has a clearly stated label (purpose) and that the appropriate keyboard shows when the user taps on it. For example, if the field is for a phone number, the numeric keyboard should be opened; if the field is for email, the email keyboard should be opened. For both iOS and Android, the keyboard would change to have the “@” key present to type in an email address easily. For Android, there will also be a “.com” key. Try to fill input fields while using VoiceOver/TalkBack.
What to report?
- Field labels are missing/unclear
- VoiceOver/TalkBack doesn’t recognize the input fields as input fields
- The wrong type of keyboard is opened
Guideline 1.4 Distinguishable
Make it easier for users to see and hear content, including separating foreground from background.
Success Criterion 1.4.1 Use of Color
What should the tester do?
Make sure that no important information for understanding or operating the app is not communicated with color only.
How?
Exploratory testing or testing with a different color scale.
What to report?
As mentioned above (this one overlaps with the criterion before): if important information is communicated through color only (you can see it often on graphs, ON/OFF indicators, and similar).
Success Criterion 1.4.2 Audio Control
What should the tester do?
If any audio in the app plays automatically for more than 3 seconds, there is an option to pause or stop the audio or to control the audio volume independently from the overall system volume level.
How?
Exploratory testing.
What to report?
Open a bug for situations where the user can’t pause or stop audio after 3 seconds or doesn’t have the option to turn the sound off (besides the system volume level).
Success Criterion 1.4.3 Contrast (Minimum)
What should the tester do?
Test that a text and images of the text have a contrast ratio of at least 4.5:1.
There are some exceptions, though:
- Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
- Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content have no contrast requirement;
- Text that is part of a logo or brand name has no contrast requirement.
How?
Since it’s very hard to test the contrast with your bare eye, the Accessibility Scanner and Accessibility Inspector should be used here.
What to report?
The Accessibility Scanner and Accessibility Inspector will recognize any text in the app as a text with too low contrast.
Success Criterion 1.4.4 Resize text
What should the tester do?
Make sure that, except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.
How?
Go into display settings and make the font 200% larger in comparison to the regular size of the font.
What to report? * The text in the app is not changed at all (it often happens on iOS when Dynamic Type is turned off). * Important information is lost due to the truncation of the text. * The screens are not scrollable, so bigger text pushes out other important components on the screen (e.g. the button on the bottom or similar). * The UI is broken weirdly.
Success Criterion 1.4.5 Images of Text
What should the tester do?
This criterion suggests that text should never be an image (besides logos) – this makes sense when we consider that it is hard to navigate through it and read it if it is an image.
How?
Exploratory testing and screen reader.
What to report?
Any text that is an image in the app.
Success Criterion 1.4.11 Non-text Contrast
What should the tester do?
Like with text, non-text content (icons) should have a proper contrast so people with visual impairments can easily distinguish it from the background. How?
This one (as well as the next one :) ) is a bit tricky – it’s hard to test it with accessibility testing tools (at least the ones we tried out) because the Accessibility Scanner/Inspector will only check the contrast on text.
What to report?
If you see any important non-text element which contrast seems a bit off, double-check with someone from the design team that it has a contrast ratio of at least 3:1.
Success Criterion 1.4.12 Text Spacing
What should the tester do?
This is one of the guidelines that applies to the web only – and it requires the following:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing the following paragraphs to at least two times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
- It’s hard to test this on mobile native apps, but it is still a good practice to have text spacing done right in the app so we make the text more readable to users.
How?
The same as the one above – it’s hard to test it with accessibility testing tools (at least the ones we tried out) because the Accessibility Scanner/Inspector will not check the text spacing.
What to report?
If you see some text that seems cramped and hard to read – double-check it with someone from the design team and see how it can be fixed.