Is the Content Perceivable?
Manual checks are needed for things that cannot be tested automatically or by assistive technologies, and to more closely investigate issues that come up during automated and assistive technology testing.
Even if no errors appear in automated checks, you’ll need to make sure that alternative text descriptions are used appropriately, check the quality and accuracy of captions, and assess whether video content requires descriptive transcripts.
Keep an eye out for how color is used throughout the site. Is it the only way some information is communicated, like when an item is selected, or whether the text is interactive. Use the TPG Colour Contrast Analyser tool (or another tool that tests contrast) to test if the text has sufficient contrast with the background. For regular text, the contrast ratio should be 4.5:1 or higher, for bigger (18pt+) or bolder (14pt+) text, and important non-text content like icons, it can be a bit lower, 3:1 or above.
You may encounter odd interactions when testing with a screen reader. These can include irrelevant content read aloud, an interaction not communicated adequately, or content read in an order different than the visual presentation. If this happens, inspect the code to see what is causing the issue. Is an important markup missing? Is the ARIA markup used incorrectly?
Try to get as good of an understanding of the issue as possible. Common mistakes will become easy to identify over time. Don’t worry if you don’t know what’s causing a particular problem. If you can’t figure it out, describe it in as much detail as possible and include it in your report along with any additional information that may be helpful. You can include a description of expected behavior and how it differs from what you’re observing. Take screenshots of information that could be helpful, like the element, the underlying code, and screen reader output, and include it in your report as well.
Is the Content Operable?
Look at the programmatic titles of your pages; they’ll appear in your browser tabs. The titles should be unique, descriptive, and organized in the reversed order of breadcrumb navigation, going from the most specific to the most general. If you’re like me and have many tabs open at any given time, you’ll appreciate it when you meet this requirement.
Next, have a look at the link text. Are pages peppered with "Read More," or "Click Here" links? This is usually very easy to fix with proper content authoring recommendations because links can almost always be associated with meaningful text within the surrounding content that can give a clear description to the destination.
What happens if you can’t find the information you need based on the navigation alone? Is there a second method for finding content? There should be at least two ways of finding information, unless the site is a series of steps, like an application form where the user moves from page to page within a constrained sequence. The first way will always be your navigation. The second can either be a site-wide search or a site map.
Make a note of any time-dependent interactions. If the site has a login component or a form with a time limit, do you get a notification before you’re the session times out?
Is the Content Understandable?
The first thing you’ll want to check is if the page language is set programmatically; this will be at the very top of your code, identified with a lang attribute in your HTML tag, e.g., <html lang=”en”>. Most automated checkers will pick up on it if the lang attribute is missing altogether, but it won’t be able to identify whether the page language is set incorrectly. It can sometimes happen if a site has multiple language versions. I once had to test a page where the content appeared in English, but the language was set to German by mistake. Because the screen reader uses the lang attribute information for pronunciation, the screen reader tried to read all of the information as if it was in German, which resulted in the text being read in a heavy German accent. The numbers were read in an entirely different language from the main content. If the page has content in multiple languages, any content in a language that differs from the main page language should have its own lang attribute.
As you get familiar with the website, notice if there are inconsistencies in the interface. If the navigation structure changes from one page to the next or if elements are named inconsistently in different sections within the site, it could throw off some users. For navigation, any links repeated from page to page should appear in the same order. For elements that repeat throughout the site, they need to be named consistently. For example, if you have several search boxes, they shouldn't be named “search” on one page and “find” on another.
Lastly, spend some extra time on any forms you encounter. Clearly describe any input that may prevent submissions, like when fields are required, or a specific format is needed (i.e., postal codes and email addresses). Clearly describe any errors. If a form flags input fields without providing any information or suggestions on how to fix the mistakes, or if the labels and instructions are missing or confusing, users are less likely to fill it out successfully.
Is the Content Robust?
First, run a validation check on the markup. You can use a tool such as Nu Html Checker, or any other validation tool. The benefit of this particular checker is that you can use WCAG only parsing bookmarklet. Not all markup errors will necessarily impact accessibility, and this bookmarklet filters out only the types of errors relevant to WCAG, allowing you to prioritize issues most likely to cause problems for assistive technologies.
The second requirement for robust content is a little bit more complicated, particularly if you’re not familiar with ARIA yet. You’ll be checking that elements have appropriate roles, states, and properties, especially when it comes to custom components since HTML markup meets this requirement by default. If you’re not yet familiar with ARIA, take the approach I discussed when we looked at perceivability. If some behaviors and interactions are unclear, describe them in detail, and explain where you observe inconsistencies between how the element works and how it is communicated to assistive technologies. After you familiarize yourself with ARIA in later chapters, and through experience, you can identify exactly which roles, states, and properties are needed to make interactions accessible.
Exercise: Manually Test Your Site
Using the WCAG testing guide prepared for you (download here as an MS Word Document or an OpenDocument), go through each criterion that calls for manual testing techniques, and note what issues you come across in your report. Remember to add screenshots and differences between the expected interaction and what you observed where necessary.
Let’s Recap!
Alternative text should be used appropriately, describing informative images, skipping decorative images, and describing the link destination rather than the image itself when the image is interactive.
Check that videos have captions and descriptive transcripts or text alternatives when the video includes important visuals.
Pages should have unique and meaningful programmatic titles.
The purpose of links should be evident either from the link text, the sentence that encloses the text, or accessible labels.
Forms need to provide clear instructions and error messages.
Now that you’re done with manual checks, the last phase is to put the site to the test with some assistive technologies. In the next chapter, we’ll look at how keyboard interaction helps evaluate alternative input and use a screen reader.
