ACCESSIBILITY FOR DEVELOPERS & QA TESTERS
Overview
These documents cover all key design foundations and should also be reviewed at the start of a project by the team. They cover all the key best website accessibility practices that are not related to a specific component design. As with many of the component documents they contain tests that the Project Manager can use as acceptance criteria for QA and techniques the Developers can use to meet those criteria.
These guides are designed to support any design system, including Google's Material Design, and can also be used to support accessible design for third party platforms such as Wordpress, SAP and Salesforce, and as such can be used in every sprint on any project.
More accessibility training and advice can be found on the following Youtube Channels:
1. Creating accessible components
When developing new component designs there can be accessibility issues that are not covered by accessibility guidelines because they are specific to a particular interaction design.
In these cases additional research is necessary to identify best practices available elsewhere on the web, so the following page will provide you with a list of components that both need some additional research and the techniques and methodologies you can use to ensure your component meets user expectations.
Where appropriate, the guidance documents contain reference implementations that demonstrate required code behaviours and provide recommended QA tests.
Testing
To enable teams to integrate testing criteria into their work plan the following accessibility testing script will help both Project Managers and Developers meet accessibility success criteria. Automated testing is also available through UTS Test Magic, Cypress, Sa11y for Salesforce and should be used in combination with the following manual testing script: Colt Developer Testing Script.
To test screen reader accessibility, use Windows Narrator to check the accessibility of your component or application. The guide Using Windows Narrator to Test Web Accessibility outlines the controls, approach and expected numbers.
Web pages can be partially tested using browser plugins. There are several commerical and non-commercial ones that run in Microsoft Edge and Google Chrome. One that is reliable, free-to-use and outputs spreadsheets that can be used to track bugs is IBM's Equal Access Tracker:
Different automated testing tools may give different results, some are commercial or semi-commercial and not all output reports. Please ensure that everyone in a product team is using the same one.
Used in combination with the manual tests in the guidelines and the testing with Windows Narrator, most use accessibility issues will be easy to spot and fix.
This overview by Sparkbox covers all of the key features of the IBM testing tool.
Component guides
The following best practice guides are taken from various third-party design systems, blogs or trusted documentation resources, and although the designs may not be exactly the same as the ones being implemented by Colt, the methodologies and techniques are still a valid way of understanding any potential issues and their solutions.
Navigation
Interactive content
Meta fields
Data input
2. Platform accessibility
If you are creating web pages, apps or components on a third party platform or framework such as Salesforce, SAP or Wordpress, each of these platforms provides guidance specific to these platforms. These should be used in addition to the Colt Accessibility Guides.
Wordpress
Salesforce
SAP
3. Colour perception
Every colour is perceived slightly and sometimes significantly differently by different people, and many people cannot differentiate between some hues at all. Ensuring that Colt's web page designs are not dependent on accurate colour perception means that no one will not be excluded because some features rely on colour in the design.
Thoughtful use of the Colt's brand colours however, can increase accessibility for some users and improve usability for many users. So rather than avoiding colour-based meaning in a web page, ensure that when colour is used as a visual cue there are alternative non-colour visual cues provided too. This is often referred to in design and engineering as 'redundancy.'
Red-green colour vision deficiency is the most usual form of so-called colour blindness disorders. It affects around 1 in 12 men and 1 in 200 women. Blue-yellow colour perception deficiency is a lot less common, and monochromatic colour blindness is rarer still. There are also other conditions such as Synesthesia, Glaucoma, Irlens Syndrome and some people with ASC that can create issues for people processing colours.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which should be performed manually
Below are a couple of examples of key questions you should ask:
Considering each of the links on the page, are they all visually identifiable without using colour? [Y/N]
When interacting with each of the features on the page (such as validation or progress indicators, is it possible to know what state each is in, even with colour disabled? [Y/N]
With regards to charts and graphs, are categories or datasets displayed on the chart keyed by a visual treatment other than colour? [Y/N]
Additional testing methods and strategies
If you are not colourblind yourself, you can test a webpage under a colour blindness simulator. The Sim Daltonism app can be installed on your mobile phone and will open a viewer that will apply a color blindness filter to anything in front of the camera.
4. Form interactions
Forms can be challenging for users with vision and / or cognitive disabilities. By ensuring that forms are well-designed and accessible is to ensure that users understand and use those forms as intended.
When web forms apply conventions and good usability practices, users are able to complete forms more quickly and with less errors in the first attempt. Forms can be gateways to Colt's content and services through log-in, opportunities for employment, the final step in becoming a customer or even the only way to raise an issue or complaint. If forms are poorly designed or implemented forms they completely exclude users with disabilities.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated
Below is an example of a test that doesn't require manual scanning:
Does each input item have a semantically valid HTML label element associated with it? [Y/N]
Tests which should be performed manually
Below are a couple of examples of key questions you should ask:
Can the entire form be completed, including making corrections of possible errors, and be submitted using only the keyboard? [Y/N]
Is the tabbing order through the form (as shown by a visible focus indicator) logical and predictable to a sighted keyboard user? [Y/N]
Are required input fields visibly marked as such, and do they use an HTML input required attribute on the input element? [Y/N]
Are error messages written and displayed in a way that makes it clear which input fields have rejected input, why the input was not accepted, and what to do to correct it? [Y/N]
Resets, timings & validation
Reset buttons
Avoid using a Reset Button on forms. They are rarely used, and it can be infuriating to have an entire completed form cleared with just one accidental click. Note that without a reset button, radio button groups may be a problem in certain cases. One of their traits is that you cannot "un-select" the group once any option has been selected in that group; you can only move the selection to another radio button in the same group. For this reason, it is recommended that a "none of the above" type of option should be included where appropriate.
Timing
Forms that time out too soon can be frustrating, especially if the process has been a long one, such as entering a specification for a quote, or applying for a job. If there is no specific need to have a timeout on a form then ensure that data is preserved for at least 20 hours. If there has to be one, make sure that it is at least 5 times longer than the time needed by an average sighted user and that the timings are conveyed in the instructions.
Validation
When validating a form, ensure that the original value entered by the user which caused the error is not cleared. By preserving the user's original value, the user can more easily identify their mistake and then fix it by editing it. Using WIA ARIA attributes can help make validation errors easier to follow by users of assistive technologies. Use the aria-invalid attribute to mark each invalid input field as having an error, and the aria-describedby attribute to associate the specific error message to that input field.
Error messages
When error messages are not displayed at all it should be considered a serious defect. When a form submission is rejected and there is no feedback explaining what needs to be corrected in order to continue, the form becomes unusable.
Error messages should be concise and specific in explaining why the form submission was rejected, and they should avoid including long strings of technical jargon. Any error codes should be explained in a non-technical way.
Check that all error messages that can be displayed meet the following requirements:
Specific: Simply saying "there was an error" or "the form is invalid" is not useful. The message should be clear which input field, or fields if there are more than one, was invalid, and why was it rejected? The name of the input field in the error should exactly match the label of the input field where the error occurred.
Friendly: Even if the user has made a mistake, the experience should feel helpful. Avoid phrases that sound aggressive, like "user error: illegal input" even if they are technically correct as they do not create a good user experience.
Actionable: Communicating that there is a problem and what the problem is is only part of the answer. The user must also know what steps they can take to fix the problem. Check that there is some information on what they need to do next in order to move forward, and if necessary provide a link to FAQs and a helpdesk.
Placeholder text
These are words that appear inside a form input and they are meant to be a nice-to-have hint. They are not replacements for proper labels, and should not duplicate a label, but provide additional instructions or hints.
Placeholders that are replacements to labels are difficult to use for keyboard users because as soon as a user tabs into the text field the instructions vanish. The contrast of placeholder text is deliberately low which is another reason why they are not replacements to labels, and placeholder text cannot wrap, so on narrow screens the user might not be able to see its entirety.
5. Keyboard access
Although there are many different types of keyboards (or equivalent switch devices) that people can use to navigate web pages, from an implementation point of view, we need to consider the following groups:
All other keyboard users, meaning users who can at least partly see the screen, who may or may not use a screen reader to augment their experience, but who depend on visual cues displayed on the screen to navigate.
Users who either have no access to a pointing device such as a trackpad or a mouse or have physical conditions such as RSI, cerebral palsy or limb differences and a keyboard is a better method for them.
The Web Content Accessibility Guidelines (WCAG) requires web page providers "ensure that, wherever possible, content can be operated through a keyboard or keyboard interface." Without keyboard support these users will be excluded from accessing your web page. A WebAIM survey of screen reader users found that a sizable portion of users indicated that "a lack of keyboard accessibility" was a problem for them. Access can include using forms, navigational menus, interactive widgets, pop-ups, alerts, and any other type of component on a page.
Focusable control elements
Link: The Enter key should activate/follow the link
Button: The Enter or Space key should activate/press the button
Checkbox/Radio Buttons: The Arrow keys should move the highlighted item, the Space key should check or uncheck the highlighted item
Select (dropdown): The Arrow keys should move the highlighted item, the Enter key should select the highlighted item
Dialog: Esc key should close the dialog
Keeping focus visible
Web browsers are already accessible when it comes to indicating which element on a web page has focus by adding a visible outline. By using CSS to style that focus, the indicator can be customised or even turned off. A missing or hard to see focus indicator should be considered a defect.
Note #1: Using Colour change alone to indicate focus would be inaccessible to users who cannot perceive colour.
Note #2: Do not disable features needed by keyboard navigation e.g. :focus {outline:none;}
Visible on focus
Content that is visually hidden on the screen, but which can receive focus via keyboard navigation, should be authored so that the content becomes visible once it has focus. An example of this would be a "Skip to main content" link, intended to allow users to quickly hop over all the navigational content at the top of every page, and continue to the main content.
Validation
When validating a form, ensure that the original value entered by the user which caused the error is not cleared. By preserving the user's original value, the user can more easily identify their mistake and then fix it by editing it. Using WIA ARIA attributes can help make validation errors easier to follow by users of assistive technologies. Use the aria-invalid attribute to mark each invalid input field as having an error, and the aria-describedby attribute to associate the specific error message to that input field.
Keyboard shortcuts
While there are many well-known keyboard shortcuts defined in desktop applications, this is not the case with the myriad of different web pages that exist. While it is possible to use the accesskey attribute to define custom shortcut keys, this is not likely to increase accessibility if users cannot predict or learn about them in an obvious way. And defining such shortcut keys could even make things worse if they conflict with built-in standard shortcuts defined in the web browser or assistive technology. See common shortcuts on the BBC GEL Megapedia.
Avoiding keyboard traps
A "keyboard trap" exists whenever a feature on a webpage prevents the user from moving away from a focused element. This should not happen of course, but poorly implemented JavaScript can sometimes alter the way keyboard focus normally works to be broken in this way if the web page author is not careful.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which should be (at least partially) performed manually
Below are a couple of examples of key questions you should ask:
Is it possible to use the Tab key to move forward, and the Shift+Tab key combination to move the focus such that each link and control can be accessed and used without a mouse or touchscreen? [Y/N]
As you move focus, it should be clearly visible which element on the web page currently has focus, for example by a consistent, visibly contrasting outline. [Y/N]
As you move focus, does each element that receives focus follow a logical, predictable order, moving from top to bottom and left to right (for web pages published in English and other left-to-right languages) [Y/N]
For interactive components, including form elements, is it possible to navigate and operate each element including setting any possible options, using the arrow keys, Enter key, Space key, etc.? [Y/N]
For complex components that automatically move focus when new content opens or appears, does focus move back to the original element once that content closes? [Y/N]
For content that is visually hidden when the web page loads, does that content become visible when keyboard focus moves into the element? [Y/N]
6. Labels for interactive elements
Form controls and other interactive elements must be labelled properly. Failing to do so will make it difficult for assistive technology users to understand the purpose of the control. Missing and mislabeled interactive elements can lead to issues or confusion for your users.
The Web Content Accessibility Guidelines state that all interactive elements should have both a label and an accessible name. The label is presented visually, and the accessible name is used by assistive technologies, like screen readers. Often the two are the same; for example, if a link wraps the text "Home", such as Home the text "Home" is the label and the accessible name.
Similarly, a button containing the text "Send" has both a visual label and an accessible name of "Send".
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which should be performed manually
Below are a couple of examples of key questions you should ask:
Is there a visible text label that identifies what kind of information is expected to be input? [Y/N]
Is the label near to the control it describes, so that it is obvious which control it is referring to? [Y/N]
Is the label still visible when the control has focus? [Y/N]
If the control is a group of selectable options, such as a dropdown menu or list of radio buttons or checkboxes, is there a visible text label describing the collection of options? [Y/N]
When controls are encountered by a screen reader is the label read aloud as expected? [Y/N]
Examples and additional information
The three aspects of labels and accessible names that must be correctly implemented are based on the user and how they interact with the web page. Having a visual label is obviously needed to allow sighted users who navigate by using a cursor or mouse to know what interactive elements are designed to do: clicking the "close tab" button, or tabbing to the "support page" link are examples.
By providing those labels in accessible ways you will also serve users of screen reader devices, which will use that text to speak the accessible name to the user. In some cases, however, it is possible to apply a visible label that is different from the accessible name. This creates potential problems for users who use voice control and speech recognition to navigate, such as by saying "click Send". These users will see the label and use that to direct their assistive technology, which in turn will rely on the accessible name. For this reason, it is recommended to keep the visible label the same as the accessible name.
Do not rely on placeholder text
Placeholder text is sometimes used by page authors as if it were an alternative for a label. This is sometimes an attempt to save space on a form since the placeholder text appears within the form input rather than next to it. But this is exactly why it is unsuitable as a label. Besides being low contrast by default, it, by design, disappears as soon as the user starts entering text into the input. And at that point there is no longer any visible label. Users with short term memory impairment or even those who are distracted and have turned away may no longer know what the label is for that input.
Do not add a title attribute
A title attribute is sometimes added to form input elements. While it is true that most screen reader devices will read out the title attribute, there is no benefit to this: using the more semantic label element would also work and comes with the benefit that the label can be clicked to focus the input. Having both a label and a title attribute of course means that both those strings of text will be read out leading to duplication.
Hiding parts of labels from screen readers
In some cases, specific parts of the text used in a label have a conventional meaning, but only when viewed. For example, the asterisk is often used to visually indicate to the user that a form item is required. While some screen readers may read out the asterisk many screen readers will not. It is acceptable to hide the asterisk from screen readers if the information is made clear in an alternative way.
Hiding parts of labels from non-screen readers
A label is often plain text but may be an element with alternative text, like an image, assuming the image is a well-understood icon. When a label is visible only as an icon, alternative text must be provided for users who cannot see the icon. Ideally the control would make that text visible for everyone along with the icon, but design limitations may not make this ideal. In that case, providing text as a label which is only accessible to a screen reader is acceptable, assuming the icon is well-known and understood to sighted users without the text (a "magnifying hand lens" icon for example, as the label to a search form).
The example below uses one of the techniques from the Alternative Text for Images section. These text alternatives will naturally be hidden from users looking at the image.
7. Landmarks
By adding HTML landmarks to your web pages, you enable assistive technologies to identify the regions which a user might want to quickly skip to, for example by using the minimum header, nav, main, section and footer tags. W3C Guide to WAI ARIA Landmarks.
A WebAIM survey of screen reader users revealed that more than half of respondents will at least sometimes use HTML landmarks to navigate within a web page. While other features, such as Headings and Links, may be used more frequently according to the survey, adding HTML landmarks into the array of virtual signposts can only be a help, particularly to users who cannot visually scan a document to decide where to start.
Navigating by HTML landmarks is a technique that can be used by both sighted and blind users, even without the aid of a screen reader device.
For users who do not have access to navigate-by-landmark features built into their web browser or assistive technology, you may provide what are known as "skip links" as a feature of the web page itself. The skip links should be the first content in the body of the web page and should link to the content identified using the main landmark.
This is helpful for users that would otherwise have to scan through lots of navigation links and header content with a keyboard for example before getting to the content they want to access. It is acceptable to hide these skip links to avoid cluttering the web page for users who navigate by pointer (mouse or touch for example) by applying CSS that causes the link to be visually hidden until it receives keyboard focus.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated:
Below are a couple of examples of key questions you should ask:
Does the web page have exactly one region identified with the main landmark? [Y/N]
Is all content on the web page contained within a landmark region? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
Are areas of the web page that are primarily meant to display navigational links identified using the nav landmark? [Y/N]
Is the web page header content identified using the header landmark? [Y/N]
Is the web page footer content identified using the footer landmark? [Y/N]
Considering other landmarks, if they are used, does each correctly communicate the content it contains: section, article, aside? [Y/N]
If a skip link exists, is that link at or near the top of the web page and can it be used when navigating by keyboard to jump to the main content? [Y/N]
8. Links
When writing text content for a link, use concise but complete text describing the linked resource. This is particularly important for people who use a screen reader to scan the entire webpage and read out a list of only the links, where each link will have no context and must be understood on its own.
For example, a series of article summaries, each containing the link with the text "Read more" will be presented as a list of many "Read more" snippets to the screen reader user, with no indication of what following any link will allow the user to read more about.
Screen reader user: "Read more" what?
Adding context to the link's text will remove barriers for screen reader users and will likely help sighted users keep track of what they are navigating to. In exceptional cases, where it would be redundant or distracting for sighted users to read the full details in the link content, this can be managed by adding the context as visually hidden text available only to screen reader users.
Although the link text visually appears as only "Read more" in the context of the article entitled "Our Values," it will appear as "Read more about our values..." when a screen reader user opens the list of all links from the webpage. Where possible, you should keep the content intended for screen reader users visually the same as content intended for other users. Not all screen reader users are blind, and screen reader users that can see the text may be confused by hearing and seeing different content.
Icons in links
While having descriptive, visible text is the most accessible way to label a link, there are use cases where a well-understood icon would be more natural. In these cases, alternative text must be supplied for screen reader users who cannot see the icon.
A simple HTML img element will display the icon. Screen readers will announce that an "image" is present and read out any text in the element's alt attribute.
See guide for Text Alternatives for Functional Images.
External links
When linking to external websites, it is a good idea from a security and accountability perspective to inform the user that they are about to visit content you are not responsible for. This can be a concern if the user is logged into your site or has some other session that would be interrupted or dropped once they leave your site.
New tabs
Opening links in new tabs or windows can make some users' experience more confusing and less accessible, so it should be used rarely. One exception may be links to external websites. If the link does launch a Modal or page in a new tab or window, make sure that this is explained in the link text.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which should be performed manually:
Below are a couple of examples of key questions you should ask:
Does each link contain visible text or a well-understood, conventional icon? [Y/N]
For links containing only an icon, is there equivalent text assigned to the graphic [Y/N]
Are all links consistently and visually distinct from the surrounding text so the user can identify them in a way that is not solely dependent on colour? [Y/N]
When navigating the web page using the keyboard, it is visually apparent when a link has keyboard focus. [Y/N]
When links are presented as a list, separate from their surrounding context, do they all have unique text or alternative text that is concise but distinctly describes the resource being linked to. [Y/N]
Is the text for all or any of the links on the page fully understandable when read in isolation? For example not using "click here" or "more information" [Y/N]
9. Metadata
Metadata is literally "data about data" and is vital for a web page to be accessible. The HTML standard defines multiple ways for web page authors to provide this metadata, including a series of aptly named "meta tags", and various other tags and attributes that declare things like the language, character set, title, and preferred viewport scale, all of which relate to the web page document.
While web page metadata can be provided using a variety of tags and attributes, what they all have in common is that they follow well-established industry standards and so are machine-readable.
Accessibility and SEO
The benefits of accurate and well-written metadata are known to apply to two types of machine-readability: search engine spiders and assistive technologies. For example, having a meaningful and well-written HTML title tag for a web page will allow Google to display that title as the clickable headline on its search results page, for the title to be included when sharing the web page on social media, and for the title to be used as the name of the bookmark in a user's web browser.
In addition, that same title will be used by screen reader devices to announce the name of the web page when it loads, so that users who may not be able to see the screen can hear an accurate and concise description of the web page's subject matter.
Validation
Validating the HTML is always a good start to checking the underlying metadata. The Web Developer Browser Extension makes this simple to do, use the menu item: Tools → Validate HTML. Evaluating the meta tags is also simplified by using this tool. Activate the menu option: Information → View Meta Tag Information for the web page under test.
Eventually, due to the nature of metadata being optimised for machines, you may need to use the view source option of your browser's developer tools to access the HTML for the web page under test directly. Look for any metadata set on the html tag or defined in the document's head section.
Declaring a web page language
The lang attribute can be added to many HTML elements to indicate what language the text in that element is written in. At the very least, the outermost HTML tag must have a language declared. If parts of the page are written in a different language (for example where a foreign phrase is intentionally quoted) that element must have a correct lang attribute value depending on the language used. If the language used does not follow the default left-to-right order for reading text, ensure that the dir attribute is also included to specify "rtl" for example, when citing a right-to-left display pattern.
Failing to set the language will likely harm your web page search engine ranking, make it more difficult for tools to render automatic translations of your content, and prevent screen reader devices from accurately using the most appropriate pronunciation engine when reading out your text content.
Make titles specific enough to be distinct
The title of a web page should be specific enough that it can be used to distinguish that web page from any other page across the entire website. By following this rule, you should end up with each web page having a unique title; otherwise, the implication is that the chosen title was either not specific enough in its description or else you have multiple web pages with the same content.
Don't disable 'Pinch and Spread' to zoom
Touchscreen devices often support gestures known as pinch and spread to allow the user to zoom in and out of specific visible areas of a web page. It is technically possible to define metadata that will disable this (by setting the maximum-scale=1 attribute for example). If this is found to be the case, it should be considered a defect.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated:
Below are a couple of examples of key questions you should ask:
Does the web page result in no HTML validation errors when checked by a W3C HTML validation tool? [Y/N]
Does the webpage have at least an overall language attribute set which follows the standard language codes for HTML? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
Does the web page have a title tag that accurately and concisely describes the subject of the entire page? [Y/N]
If the web page is viewed on a touch screen that supports pinch and spread to zoom, is it possible to use these gestures to zoom in out of the page? [Y/N]
10. Enhancement & responsive design
Progressive enhancement ensures that users can use the widest possible array of devices and software, whilst the core purpose of the web page is still usable and understandable. Additional nice-to-have features can be added onto that core experience for the benefit of more capable devices and web browsers.
Robust accessibility
Applying progressive enhancement practices will make your web page more resilient as well as inclusive; not every user will have the fastest connectivity, most powerful computer, or latest software installed. and sometimes a feature may be turned off by a user deliberately. You should assume they have a good reason for this decision, but not every user has a choice.
1. Ensure text is resizable
Text is considered usable and readable when it is not cropped and does not overlay other text or nearby elements. It should wrap as needed and maintain its typographical qualities, allowing sufficient line-height and letter and line spacing for example. Ensure that relative units (ems or rems) are used to specify the sizes of web page elements like text and layout. This will enable the page to scale and adapt relative to the size of a device screen or its orientation (portrait or landscape).
2. Ensure the web page is zoomable
Page zoom increases the apparent size of the entire page, while text resizing only increases the size of the text. Ensure all content is visible and usable when the web page is zoomed to at least 200% of its default level.
3. Adjust touch targets to be larger on smaller screens
On mobile devices with touchscreens the user must contend with both a smaller physical screen and the use of a finger to try to tap the targets such as links or buttons. Taking this into consideration, the minimum physical touch target size should be at least 7 x 7 mm, or larger if possible. This will undoubtedly require increasing the size of interactive elements on smaller screens.
4. Don't rely on a noscript fallback
Some web pages use a noscript HTML tag to define alternative content for web browsers where JavaScript has been turned off. Research done by Gov.uk showed that a significant portion of users who could not run JavaScript did not have JavaScript turned off. In other words, JavaScript was turned on but didn't run for some other reason. This matters because a web browser will only show noscript content in the specific case that JavaScript was turned off. When JavaScript doesn't run for another reason, the user will not see the content that requires JavaScript, nor will they see any noscript alternative content.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated:
Below are a couple of examples of key questions you should ask:
Are all sizes specified in the design (CSS) of the webpage declared using relative units (ems or rems) only, avoiding the use of fixed, pixel-count units like px? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
When the text size is modified to 200% of its default size in the browser settings, is all text on the web page still visible and readable? [Y/N]
When the page zoom is increased to 200% in the browser, does all text on the web page increase proportionally? [Y/N]
In DevTools, with the browser CPU and Network Throttle simulator set to their most degraded settings, is the core purpose of the page still delivered? [Y/N]
In DevTools, when the browser has its Device Mode simulator set to the smallest available device screen, is the core purpose of the page still delivered? [Y/N]
Additional test practices
You can use tools like the Chrome Browser DevTools, and apply the Device Mode settings to approximate the web page under test on a range of devices: from mobiles, to tablets, and desktop. You can even simulate device inputs for touch, geolocation and device orientation.
Note that the Network Tab enables you to simulate CPU and network throttling.
11. Semantic structure
Within any web page, headings are used to communicate the overall organisation and structure of the content. The headings should act as a high-level outline of the page content, with a logical ranking of each topic and subtopic in hierarchical order.
A WebAIM survey of screen reader users revealed that 67.5% of respondents are most likely to try headings first to find information on a lengthy web page. And 85.7% said that having proper heading levels was useful when navigating a web page by headings.
Failing to provide usable and well-organised headings prevents screen reader users from understanding the structure of your content and from being able to navigate within your page efficiently. While headings are useful for everyone, users of assistive technology are excluded more than others when headings are missing or improperly implemented.
Headings
The h1 heading should describe the subject of the web page as a whole and so would be similar or identical in content to the web page's title element.
It is typical for the very first heading to be h1 but it is not a defect for an h2 to appear first, for example. The logical ranking and order of headings is more important than which is first, for example ensuring that no h2 is followed next by an h4 (skipping the expected h3). To illustrate, if the navigation portion of the page appeared before the displayed title of the page, you might give the navigation heading a rank of h2 but then further down use an h1 heading to indicate the main subject matter of the entire page.
Screen reader devices are not able to recognize elements that are only visually styled as headings as being true headings. Use a tool that can check the HTML source to find the actual headings (which is exactly how screen reader devices do it) and only use a div for what it was designed for, and never use it as a replacement for other more appropriate tags. For a more authentic experience of navigating the headings, use the Narrator Screen Reader built into your Windows machine to test the page.
This will make the importance of the H1 inaccessible to screen reader users.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated:
Below are a couple of examples of key questions you should ask:
Do HTML heading tags like h1 and h2 appear in the HTML for the page? [Y/N]
Are the headings in a hierarchical order without skipping heading levels (from h2 to h4 for example)? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
Are headings displayed in a consistent and recognizable style which makes them easy to identify versus other non-heading content? [Y/N]
Does the text of each heading correctly and concisely describe the subject matter which it heads? [Y/N]
Does the primary h1 on the page correctly and concisely describe the subject matter of the total page? [Y/N]
Are all examples of text that are visually styled to look like headings implemented with an HTML heading tag? [Y/N]
12. Text alternatives
Where the user does not have images available in their web browser or where the user cannot see images due to an impairment, text alternatives MUST be provided that act as a comparable source of information and utility so that the user can still access, understand and use the web page for its core intended purpose.
This document covers the techniques and testing necessary for ensuring functional images such as icons, buttons, controls, logos, and brand assets are accessible to screen reader users.
It also covers techniques for identifying content images, however the tests will not conclusively prove that any content images are accessible. Never rely on an automated AI alt text generation tool. Functional images require a text alternative that describes what they do or stand for rather than what they look like. A visual description of a button or icon is of little or no use to a user.
Purely decorative images
These images add no meaning to the content of the web page and so should be silently ignored by screen reader devices. By definition, decorative images could be deleted without affecting the understandability and usability of the page.
Similarly, background images (defined in CSS) are automatically ignored by screen reader devices so must only be used for purely decorative purposes.
There is a frequently abused edge-case where the element displaying the background image is authored to contain text meant to be an alternative to the image, rather than defined in an HTML alt attribute.
Notice that the alternative text is in the body of the web page but is styled (via a developer-defined visually-hidden class to only be accessible to users of a screen reader device. While this is technically accessible to screen reader users, it is a worse approach than using an img element with an alt attribute because the visually hidden text will never be revealed when images are disabled or for any reason fail to load, whereas the alt attribute text will.
Content images
These images are intrinsic to the content or utility of the page. Use the HTML alt attribute to provide a textual alternative for the image.
Be careful not to provide redundant content, however, if the text used as an alternative for the image is already nearby in the regular body text, then the alternative text should be considered redundant, and the image should therefore be treated as purely decorative. Otherwise, the screen reader experience will be to hear the same text read aloud twice.
When evaluating the quality of alternative text consider the editorial meaning and purpose of the image in the context of the surrounding page. The alternative text should concisely impart what the image means, not just what it shows.
Do not assume that other HTML features intended to provide alternative text, such as the longdesc, title or figcaption attributes, will work for screen readers. It is not predictable whether any particular screen reader device (depending on how it is configured) will either ignore those attributes or if it will read any or even all of them.
If the amount of text information required is large or complex, it is acceptable to use an ARIA attribute to mark another adjacent HTML element as the alternative text.
Images in controls
When images act as the label of a control – think of an image of a social media logo that is the only content in a link to the company social media feed – then the control must be accessible for users who cannot see the image. Use alternative text that explains the action of the control. A link should describe the destination, for example "Home Page", "About us", etc. An image in a button should use alternative text that describes the purpose of the button, such as "Search", "Log In", or "Submit" for example.
Graphics in SVG format
In some cases, the image displayed may not be defined using a traditional img tag, but it must still be possible for screen reader devices to access some textual alternatives. The example below shows a technique documented by Léonie Watson which uses a combination of role, and aria-labelledby attributes referring to a title and desc to help assistive technology users access text that describes the graphic.
How to test this
For each web page, perform the following checks. Record an answer, "yes" or "no" to each question. The passing result is indicated in uppercase after each question e.g. [Y/N] where Y is required to pass. For each failing result, document it as one of the following:
As a defect
A defect, but with an explanation of why it should be allowed as an exception
A defect, but with an explanation of why it is not applicable
Tests which could be automated:
Below is an example of a key question you should ask:
Does each image have alternative text associated with it (even if that text is an empty value)? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
Is the alternative text concise, grammatically correct, and free of spelling errors? [Y/N]
If the image purpose is purely decorative, is the alternative text an empty value, like alt="" ? [Y/N]
Does the alternative text describe the image in a way that communicates a comparable meaning to users who cannot see the image? [Y/N]
If the image appears as the only label for a control, a link or button for example, is it possible to understand what the control does solely from the alternative text? [Y/N]
Is the alternative text original / useful and not just repeating adjacent body text? [Y/N]
Does the language used for the alternative text match the language declared for the rest of the document? [Y/N]
If the image is a brand logo and is not functional, does it simply state the name of the brand? [Y/N]
If the image is, for example, a Diageo icon, does it use the text associated with that icon as outlined in the design system? [Y/N]
Tests which could be automated:
Below is an example of a key question you should ask:
Does the automated contrast checker indicate no contrast errors? [Y/N]
Tests which should be (at least partially) performed manually:
Below are a couple of examples of key questions you should ask:
With blurred vision emulation enabled, is it possible to easily read text that overlays images or gradients? [Y/N] Note: seek the opinions of at least 2 other people connected with this project
Emulating blurred vision
Sufficient contrast is particularly important when users may be experiencing your web through blurred vision, when in bright glare, or when distracted. Enabling blurred vision emulation is a fantastic way to test that text is adequately legible.
On the Chrome browser, this emulation is available by following the steps below:
Type the keys: command + shift + p and then enter (type) the text "render" to see all available rendering options
Scroll down to the "Emulate vision deficiencies" dropdown
Then select the "Blurred vision" option
To check contrast and legibility for users who may have colour perception deficiencies, choose the "Achromatopsia" (removing all colour) option.
Additional information
Disabling images (also an option via the Web Developer browser extension) is an effective way to ensure that text that was designed to appear overlaying an image will still be legible if that image should happen to not appear. Setting a fallback background colour on such elements with background images is important to handle such cases.
14. Using Windows Narrator
Narrator is a screen reader that is built into all Windows operating systems. This guide is designed to help Developers and Testers who are new to Narrator learn the basic controls for testing their web pages.
Narrator currently works best with the MS Edge browser, but it also has support for Chrome and Firefox.
Getting started
To Start or Stop Narrator, press the Windows key + Ctrl + Enter. This will open a window with options to learn more about Narrator and configure your settings. If you are new to Narrator, watch this video for a quick introduction tutorial.
Useful things to remember:
Press the Windows key + Ctrl + N to access the settings. Here you can alter the voice, relative volume, and speed.
Both the Caps Lock and Insert keys can be used as the Narrator "modifier" key used in many commands—we will call the Narrator key.
Ctrl + Home: will take you to the top of the page
Ctrl + R: will refresh the page (useful if you are lost or if Narrator is not behaving as expected)
For a full list of Narrator Shortcuts https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
Listening to web content
There are multiple ways of using Narrator to access web content. There are the most useful keys:
Ctrl + ↑/↓: Read previous/next line
↑/↓: Read previous/Next paragraph or item
Narrator + Tab: Reread current item
Narrator + +/-: Increase/decrease speech rate
Ctrl: Stop reading
You may want to practice reading through some different pages before you start testing.
Testing page navigation
Most sighted users will skim and take in a visual snapshot of a webpage to get an idea of where everything is, but you can't do that then what the page contains in terms of headings, images, form elements, messages etc is unknown. If a web page is well structured and has followed the Colt Accessibility Guides, a user should be able to navigate the page using the Headings, Landmarks, Links or Lists etc.
There are several single-key shortcuts to quickly navigate by common page elements. Check that these work and you can access each type of element successfully.
These include:
H: Headings
1 - 6: Heading 1, heading 2, etc.
D: Landmarks
Tab: Links and form controls
F: Form controls
B: Buttons
K: Links
L: Lists
I: Items in a list
T: Tables
Shift + Any navigation key reverses the action.
Open the Find Dialog and try searching for different elements
Narrator + Ctrl + F : Open the Find dialog
Narrator + F3: Move through Narrator Find results (add Shift to go backward)
Navigation Accessibility Guidance
Testing forms
When a form control gets keyboard focus, Narrator reads the label (if there is one), and then announces the type of form control. If a group of form controls—typically groups of checkboxes or radio buttons—is contained in a fieldset with a legend, Narrator presents items in a fieldset as a group and reads the legend when you first navigate to anything within the group.
Use the following browser keyboard controls to interact with form controls and test whether they can be navigated to, and whether their labels are both unique and descriptive.
Tab and Shift + Tab: Navigate through form controls
Space to select and deselect checkboxes
↑/↓: Select from a group of radio buttons
Space, then ↑/↓ or the first letter of an option: Expand and then select an option in a combo box
Enter: Submit a form
Forms Accessibility Guidance
Testing images
Images can either be Functional, Content or Decorative. Colt's Stream Graphics are mostly aesthetic and so would be classed as decorative. This would mean they should be silent to screen readers. If alternative text is not defined, Narrator will typically say "image" or "unlabeled graphic" (most other screen readers ignore these). A functional or content image's alternative text will be read by Narrator and should describe the purpose of the use of the image.
Examples:
Colt Logos should just say the name of the brand, "Colt Technology Services"
Co-branding logos should say both brand names, "Colt Technology Services in Partnership with Cisco"
Colt Icons or ESG visuals, should simply state the purpose of what the image stands for.
Images that are links, if the Colt logo is also a link to the Homepage, should accommodate both the brand name and destination, "Colt homepage".
Images Accessibility Guidance
Testing data tables
To navigate to the next table in a page, press the T key. To navigate within a data table, hold down Ctrl + Alt and use ↑/↓/←/→ to move from cell to cell. If a table has proper row and column headers, they will be read automatically while navigating.
Ensure the rows and columns have meaningful labels.
For a full list of Narrator Shortcuts: https://dequeuniversity.com/screenreaders/narrator-keyboard-shortcuts
15. Downloads
To make it easier for developers to test for potential accessibility issues, we've created an Manual Accessibility Checklist to structure your tests.
Last updated
Was this helpful?