Accessibility Testing Baselines

The following subset of WCAG 2.1 Success Criteria make up the baseline of accessibility guidelines Radancy strives to meet in our products and websites. These guidelines are representative of the most common accessibility barriers and issues we encounter on a day to day basis and so, believing accessibility to be critical, we make a good faith effort to always be on the lookout for them. However, there are no guarantees we are meeting any level of compliance without full accessibility testing being performed, so if there is a need to fully support WCAG, please bring this to the attention of your account representative as soon as possible.

Please note that these baselines are subject to change as guidelines and our understanding of accessibility continue to evolve.

Overview

Provide text alternatives for non-text content, such as images. Understanding 1.1.1

Who is responsible? Designer, Copywriter, Content Producers, Developer

Images

Understanding Image Types

Generally, images fall into one of several categories. It is very important to understand the difference between these image types in order to make a more informed decision on whether to include an alternative text value or not and what kind of value you may need to add.

  • Decorative: Images that add accent or embellish. If content on the page can be experienced and understood without these images, then an alternative text value is not required.
  • Functional: Images that indicate action to be taken, rather than a description of the image. Functional images are found within interactive elements, such as hyperlinks or buttons.
  • Informative: Images that provide value to the surrounding content. If content on the page can't be experienced or understood without these images, or content is locked within image, then an alternative text value is required.
  • Images of Text: Images that contain text. The alternative text used within this image type should often be verbatim.
  • Complex Images: Images such as graphs or diagrams. These image often contain detailed information, so alternative text is not adequate here. This content should be conveyed through alternative text equivalents.
  • Groups of Images: Multiple images that convey a single piece of information. In this case, the text alternative for one image should convey the information for the entire group.
  • Image Maps: While used rarely, the text alternative for an image that contains multiple clickable areas should provide an overall context for the set of links. Also, each individually clickable area should have alternative text that describes the purpose or destination of the link.
The Rules
  1. All inline image elements require an alt attribute. For example: <img alt="" src="...">. An image with an alt attribute that has no value, is known as a "null alt". Images with a null alt are ignored by assistive technology.
  2. If image is informative or contextually important to surrounding content, then it must include an alternative text value. Some things to ask yourself about images:
    • Are they meant as labels?
    • Do they supplement or enhance surrounding content?
    • Are they meant to convey an impression or emotion?
  3. If image contains complex information, then alternative methods of conveying this information will be required as alternative text may not suffice. For example, a graph or chart may require the information be marked-up in HTML and linked to, etc.
  4. If image contains text, then it must include an alternative text value if same information not conveyed nearby. Typically verbatim, to match what is embedded in the image.
  5. If image is purely decorative, then it requires no alternative text value. While an img element that is decorative must contain a null alt, a decorative SVG element will require aria-hidden="true". For example: <svg aria-hidden="true" ... ></svg>
  6. If image is functional and contained within an interactive element (e.g., a hyperlink or button), then it must contain alternative text if no other functional text present within. For example: <a href="..."><img alt="My Awesome Vacation (Video)" src="..."></a>
  7. Avoid superfluous phrases like "Image of ..." or "Picture of ..." as these are redundant to assistive technology (AT) users.
  8. Background images are important if picture within is informative. The first rule of ARIA is to always use HTML, so an <img> element should be used, but in a pinch, the following may be acceptable: <div aria-label="..." role="img"></div>

Accessibility Tip

Alternative text should be written in a descriptive, yet succinct manner. Think of how you might describe an image to a friend who is blind. For example:

A little boy sitting on his mother's lap. Both are smiling and wearing American paraphernalia.

Note: Unless it is relevant to the image, intentionally including keywords in alternative text descriptions, for the sole benefit of SEO (Search Engine Optimization), is strongly discouraged. Websites are for people; not machines.

Testing

Review images and ensure that the aforementioned rules are met.

Resources

Overview

Provide text alternatives for non-text content, such as multimedia (audio, images, video) and interactive components (buttons, controls, inputs). Understanding 1.1.1

Who is responsible? Developer, Designer

Components and Multimedia

The Rules
  1. Ensure that interactive components (e.g., buttons, controls, inputs), have an accessible name. Interactive elements that are not visually labeled, must still include an accessible name.
  2. If text is not explicit in the design of a component, then use various methods to provide this information. Accessible names can be applied in various ways, such as with, labels, inclusively hidden techniques, and with ARIA.
  3. Ensure that multimedia is identified via accessible text. For example: <video src="..." controls aria-label="My Summer Vacation">...</video>
  4. Ensure that inline frames (iframe) are appropriately titled and describe contents of the frame accurately. For example: <iframe src="..." title="Job Application Form">...</iframe>.

Testing

Review page components and ensure that the aforementioned rules are met. Here are some important things to be on the lookout for during review:

  • Are label elements associated with specific form controls? Is the label element being hidden with display: none?
  • Are placeholder attributes being used to stand-in for labels? Inappropriate use of placeholders can have a negative impact on the user experience.
  • Are iframe and multimedia elements, like audio and video properly labeled?
  • Is ARIA being used to provide an accessible name for user interface controls?

Resources

Overview

Provide captions for videos with audio Understanding 1.2.2

Who is responsible? Developer, Content Producers, Digital Project Manager

Testing

  • Video on a page should be manually reviewed. If the video includes spoken dialogue or important information, then it must contain captions .
  • Caption accuracy is also critical. If a video is found to have inaccurate captions, new captions must be produced. See Creating Accessible Multimedia.
  • Some advanced issues to be on the lookout for include:
    • Caption synchronization. Viewers can tell when captions are out of sync without sound.
    • Caption length. This makes a difference in preventing cognitive overload.
    • Caption position. Bottom except for temporary movement to the top for on-screen text like credits.
    • Sound.
    • Credits. Viewers want to see both captions and credits or whatever is on-screen.
    • Voice changes.
    • Speaker identification
    • Flow / movement

Note: While not a failure here, providing transcripts with video and audio content is becoming a necessity and strongly encouraged. Including them would pass 1.2.1 Prerecorded Audio-only and Video-only, which is not currently included in our baselines, but will be eventually.

Resources

Overview

Semantic markup is used appropriately. Logical structure, etc. Understanding 1.3.1

Who is responsible? Developer

Testing

HTML should be structured and labeled accordingly, so that the page makes visual and structural sense to everybody. Here are some important things to be on the lookout for during review:

  • Is semantic markup being used to convey proper structure and meaning to assistive technology users?
  • Are headings (h1-h6) being used properly to identify content hierarchy? Are any empty headings present?
  • Are lists being marked up and implemented correctly?
  • Are label elements associated with specific form controls? Is the label element being hidden with display: none?
  • Are iframe and multimedia elements, like audio and video properly labeled?
  • Is table markup being used to implement tabular data only?
  • Does the page identify its language properly via the lang? Are shifts to other languages present within the page?
  • Is ARIA being used to properly identify landmarks and regions of a page?
  • Is ARIA being used to provide an accessible name for user interface controls?

Resources

Overview

Don't use presentation that relies solely on color. Understanding 1.4.1

Who is responsible? Designer, Developer

Testing

  • Manually ensure that color is not used as the sole method of conveying content or distinguishing visual elements. For example, saying "Please correct all text highlighted in red", would be a failure.
  • For better usability, links should be underlined by default. Otherwise, link text must:
    1. Have a 3:1 contrast ratio with surrounding body text, and must present a visual indicator (typically an underline) when hovering over or receiving focus.
    2. Both link and body text must have a 4.5:1 contrast ratio with the background (3:1 for large text).
    3. Links in the header and footer are typically understood to be a link, so the above rules may not apply.

Resources

Overview

Contrast ratio between text and background is at least 4.5:1. Understanding 1.4.3

Who is responsible? Designer

Testing

Review page and test any text or images of text that you suspect may fail this guideline. Running the WAVE validator may also be helpful.

This rule does not apply to the following:

  • Large Text: Large text and images of large text have a contrast ratio of at least 3:1. Note: In WCAG, points are often referred to as the unit of measure in determining the size between regular and large text. However, pixels are much more common on the web. 18pt maps to 24px and 14pt to approximately 18.67px. In CSS, bold text typically has font-weight: bold, or font-weight: 700 or greater.
  • Incidental: Text or images of text that are part of an inactive user interface component (i.e., disabled button), 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.
  • Logotypes: Text that is part of a logo or brand name has no contrast requirement.

Overview

Text can be resized to 200% without loss of content or function. Understanding 1.4.4

Who is responsible? Developer

Testing

  • Use Control (PC) or Command (Mac) and + keys to increase zoom level of browser viewport. When 200% is reached, test to see if all page content can still be accessed and that site continues to be fully operable and usable.
  • Page zoom should never be intentionally disabled. If the page cannot be zoomed in on at all, it is failure.

Overview

Ensure important visual components, such as images, icons, and buttons, have a contrast ratio of at least 3:1. Understanding 1.4.11

Who is responsible? Designer

Testing

Ensure that the visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):

  • User Interface (UI) Components: Visual information required to identify user interface components and states, except for inactive components or where the appearance of the component is determined by the browser.
  • Graphical Objects: Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.

Review page and test any UI components or images that you suspect may fail this guideline. Running the WAVE validator may also be helpful.

Overview

Accessible by keyboard only. Understanding 2.1.1

Who is responsible? Developer

Testing

  • Using your Tab key, navigate through the page and engage with interactive components. Anything that can be used with a pointing device, such as a mouse, must be equally usable via keyboard.
  • Anything that receives focus must have an accessible name.
  • Ensure that interactive components on the page work when accessed with Enter key. Buttons will be expected to work with both the Enter and Spacebar keys.
  • See where focus is brought when certain components are engaged with. For example, what happens when a button is accessed and a modal is shown? Will continuing to tab take you behind the modal, or keep you within the modal itself?
  • Does keyboard focus become trapped within any portion of the interface while tabbing? While this is acceptable behavior in modal dialogs, in other scenarios it could be an indication of a keyboard trap.
  • Non-interactive elements, such as a div, should not receive keyboard focus while tabbing.

Accessibility Tip

Buttons do things; hyperlinks take us places.

The difference between using a hyperlink and a button can have a very big impact on accessibility. By using the correct element for the job, we can set the right expectation for AT users and make our code much easier to write. Be sure to read Pushing Buttons for more details on why this distinction is important.

Overview

Provide user controls for moving content. Understanding 2.2.2

Who is responsible? Designer, Developer

Testing

  • Manually check to see if the page contains automatically moving content, such as a carousel or video. If such features have no mechanism to pause them, then this is a failure.

Accessibility Tip

Unless there is continuous movement, subtle web (a.k.a micro) animations are typically exempt from this rule, but it is strongly recommended that development leverage prefers-reduced-motion in their work to avoid creating an unpleasant experience for those who may find animation problematic.

Overview

No content flashes more than three times per second. Understanding 2.3.1

Who is responsible? Everybody

Testing

  • A high rate of flashing can cause potential harm, or even death, in individuals with epilepsy. If you suspect that any feature on a page is harmful, you can download and install PEAT (Photosensitive Epilepsy Analysis Tool) to see if there is any risk or reach out to the Accessibility Team to perform this test for you.

Important: Any suspect animation or failures should be immediately brought to the attention of Michael Spellacy.

Overview

Provide a 'Skip to Content' link. Understanding 2.4.1

Who is responsible? Developer

Testing

  • Areas of a web page that may be cumbersome to navigate through via keyboard or assistive technology, must provide a mechanism to skip over that content. These "Skip" links should be available to all users when needed and not obscure other content on the page when visible. You will often find these links placed before a websites primary navigation, but they can be useful elsewhere. If it takes you a long time to tab through a certain portion of the interface, then this may be a good indication that a skip link is necessary.
Screen grab of a website, with a 'Skip to Main Content' hyperlink.
An example of a "Skip" link. These links, when present, will display when keyboard testing is performed. If it perfectly normal for the mechanism to be present for all user types.

Overview

Use helpful and clear page titles. Understanding 2.4.2

Who is responsible? SEO, Copywriter, Content Creators

Testing

Ensure that all pages have a title and that it is useful and adequately describes the page at hand. Pages that are dynamic in nature, such as those found when utilizing React or similar frameworks, will need their title element continuously updated.

Overview

The navigation order of links, form elements, etc. is logical and intuitive. Understanding 2.4.3

Who is responsible? Developer, Designer

Testing

  • Navigate through the page using the Tab key on your keyboard, while being mindful of the focus order. Tab stops that are not in a fairly logical visual order should be considered a failure.
  • An interactive element with a tabindex other than 0 will interfere with a pages natural tab order and should be considered a failure. A tabindex with -1 will not interfere with tabbing.

Overview

Ensure keyboard focus is visible and clear. Default focus outlines are a browser feature meant to aid those with low vision, and should never be removed without an adequate replacement. If default focus outlines are undesirable, they may be redesigned or an alternative focus state can be used. However, any redesigned outline or alternative focus state must then meet a 3:1 contrast ratio. Understanding 2.4.7

Who is responsible? Developer, Designer

Testing

  • Using your Tab key, navigate through the page and review all focus states of interactive elements. If focus state is missing or an alternative and adequate focus state is not provided, then this is a failure.
  • Again, any redesigned focus state must meet a 3:1 contrast ratio.
  • Non-interactive elements should not contain a focus state. The only exception to this rule is if the non-interactive element is accepting temporary focus via tabindex="-1".

Overview

No major code errors. Understanding 4.1.1

Who is responsible? Developer

Testing

Validate the page and address or report any major code errors you may discover. Warnings may be omitted, but should be addressed as time permits.

Overview

Build all elements for accessibility. Understanding 4.1.2

Ensure that each element has an accessible name, role, value, state and property which can be properly conveyed to AT users. How an interface is conveyed to AT users is as equally important to how they are conveyed to users who do not rely on assistive technology to access the web. For example, if a screen reader user accesses a disclosure component, how might the fact that it is opened be conveyed to them? Is the correct state of the component, or any state at all, being presented in this scenario? Using semantic HTML along with properly implemented ARIA can assist us in creating an equal and accessible experience for everybody.

Who is responsible? Developer

Testing

Be sure to ask yourself some of the following questions:

  • Is ARIA being implemented on the page? Is it used correctly? Do accessible names, roles, values, states and properties make sense? Can HTML be used instead of a custom control?
  • Is form markup correct? Is labeling present and correctly associated with its input field?
  • Do iframe's have an accessible name? Does that name describe the contents of the iframe adequately?

Validation

Be sure to validate your work.

Some of the following issues may not specifically fall under WCAG, but are considered industry-wide best practice and strongly suggested.

Who is responsible? Everybody

Carousels

Radancy UI/UX discourages use of carousels whenever possible and instead recommends alternative forms of page layout. While carousels may be useful in certain situations, they can bury important content you may wish for users to access and engage with and are often inaccessible. Approach usage with caution. Check out Should I Use A Carousel? for more information.

Important: Slick is a popular plugin that many developers use to easily implement a carousel. If a carousel is required, please only use the approved version, Accessible Slick, in new implementations.

PDF
  • When possible, a PDF should never be used over HTML. PDF files often have accessibility issues that can only be remediated by a PDF specialist. Should PDF's require accessibility testing and/or remediation, please contact Michael Spellacy.
  • When linking to a PDF, it is customary to include the file type, visually, within the link itself. For example: <a href="../docs/legal-waiver.pdf">Legal Waiver (PDF)</a>. PDF's are common in our footers but can also be found in other areas of our sites, pointing to brochures or other company related information. By including this helper text, we are setting a better expectation for users as to what will happen when the link is accessed.
New Tabs (Windows)

Launching new tabs should only occur in the rarest of circumstances and, if required, be approached with care and caution. Here are some points to consider:

  • Ask Why - One should have an excellent reason to spawn a new tab. Opening new tabs, just to keep users on your site, is not a good enough reason.
  • Trust Users - Let your users decide if opening a new tab is the best course of action.
  • Accessibility - If a new tab is a necessity, use aria-label or alternative techniques for assistive technology and include visual indicators.
  • Security & Performance - If a new tab is a necessity, make use of rel="noopener". This will prevent "tabnabbing" and improve page load between parent and child tabs.

You can learn more about this best practice by reading The Last Word (Maybe) on Opening New Windows.

Accessibility Overlays

Accessibility overlays are strongly discouraged and not in line with Radancy's vision on how best to support people with disabilities in our digital offerings. In our experience, use of these tools may promote ableism, reinforce discrimination and are often perceived, particularly among the disabled and advocacy communities, as a performative commitment to accessibility. Companies using overlays have frequently been subjected to legal actions based on non-compliance with accessibility laws and principles. Upon request, we are happy to share materials addressing the challenges faced by users of websites that include overlays.

If you would like to discuss this issue, along with more proactive, friendly, and sustainable ways to make your careers site accessible to everybody, please reach out to your account representative.

About the Author

Michael Spellacy

Michael "Spell" Spellacy is the Director of Accessibility at Radancy. If you have any questions, feel free to contact him on Github or see what he is up to on his blog.