WCAG Application Readiness

  1. Home
  2. Accessibility
WCAG Application Readiness
Overview

Accessibility: the result of the removal of any barriers which prevent interaction with a product, device, service or environment by people with disabilities. Successfully addressing web accessibility concerns enables people with disabilities to equally perceive, understand, navigate, and interact with websites and applications.

Most studies find that approximately one fifth (20%) of the population has some disability. Not all these people have disabilities that make it difficult to access the internet, but this is still a significant portion of the population. Not taking into consideration the needs of 20%, 10%, or even 5% of our potential customers would not only be contrary to our core business values, but in some cases, it would also prevent Brightree from winning new business.

In 2010 the U.S. Department of Justice released the 2010 ADA Standards for Accessible Design. This update to the Americans with Disabilities Act (ADA) of 1990 has consistently been interpreted by U.S. courts to apply to digital content, including websites, applications, mobile apps and PDFs.

Brightree products should ultimately be certified as compliant with Web Content Accessibility Guidelines (WCAG) 2.0 Levels A and AA, the Revised Section 508 standards as published by the U.S. Access Board, and also with EN 301 549 Accessibility requirements suitable for public procurement of ICT products and services in Europe.

It’s important for product teams to understand that, while clearly establishing a solid foundation, implementing the Brightree UI components alone does not guarantee your product is 508 compliant. Additionally, a partial implementation of Brightree UI styles, or overriding Brightree components with customizations, may negatively impact 508 compliance already established within the UI.

Principles
Perceivable

Text alternatives for non-text content

Text alternatives are equivalents for non-text content. Examples include:

  • Short equivalents for images, including icons, buttons, and graphics
  • Description of data represented on charts, diagrams, and illustrations
  • Brief descriptions of non-text content such as audio and video files
  • Labels for form controls, input, and other user interface components
Captions and other alternatives for multimedia

People who cannot hear audio or see video need alternatives. Examples include:

  • Text transcripts and captions for audio content, such as recordings of a radio interview
  • Audio descriptions, which are narrations to describe important visual details in a video
  • Sign language interpretation of audio content, including relevant auditory experiences
Content can be presented in different ways

For users to be able to change the presentation of content, it is necessary that:

  • Headings, lists, tables, input fields, and content structures are marked-up properly
  • Sequences of information or instructions are independent of any presentation
  • Browsers and assistive technologies provide settings to customize the presentation
Content is easier to see and hear

Distinguishable content is easier to see and hear. Such content includes:

  • Color is not used as the only way of conveying information or identifying content
  • Default foreground and background color combinations provide enough contrast
  • When users resize text up to 400% or change text spacing, no information is lost
  • Text reflows in small windows (“viewports”) and when users make the text larger
  • Images of text are resizable, replaced with actual text, or avoided where possible
  • Users can pause, stop, or adjust the volume of audio that is played on a website
  • Background audio is low or can be turned off, to avoid interference or distraction

Operable

Functionality is available from a keyboard

Many people do not use the mouse and rely on the keyboard to interact with the Web. This requires keyboard access to all functionality, including form controls, input, and other user interface components.

Keyboard accessibility includes:

  • All functionality that is available by mouse is also available by keyboard
  • Keyboard focus does not get trapped in any part of the content
  • Web browsers, authoring tools, and other tools provide keyboard support
Users have enough time to read and use the content

Some people need more time than others to read and use content. For instance, some people require more time to type text, understand instructions, operate controls, or otherwise complete tasks on a website.

Examples of providing enough time include providing mechanisms to:

  • Stop, extend, or adjust time limits, except where necessary
  • Pause, stop, or hide moving, blinking, or scrolling content
  • Postpone or suppress interruptions, except where necessary
  • Re-authenticate when a session expires without losing data
Content does not cause seizures and physical reactions

Content that flashes at certain rates or patterns can cause photosensitive reactions, including seizures. Flashing content is ideally avoided entirely or only used in a way that does not cause known risks. Animations and moving content can also cause discomfort and physical reactions.

Examples of avoiding causing seizures and physical reactions:

  • Do not include content that flashes at particular rates[BM1] and patterns
  • Warn users before flashing content is presented, and provide alternatives
  • Provide mechanisms to switch off animations, unless they are essential
Users can easily navigate, find content, and determine where they are

Well organized content helps users to orient themselves and to navigate effectively. Such content includes:

  • Pages have clear titles and are organized using descriptive section headings
  • There is more than one way to find relevant pages within a set of web pages
  • Users are informed about their current location within a set of related pages
  • There are ways to bypass blocks of content that are repeated on multiple pages
  • The keyboard focus is visible, and the focus order follows a meaningful sequence
  • The purpose of a link is evident, ideally even when the link is viewed on its own
Users can use different input modalities beyond keyboard

Input modalities beyond keyboard, such as touch activation, voice recognition (speech input), and gestures make content easier to use for many people. Yet not everyone can use each of these input modalities, and to the same degree.

Particular design considerations maximize the benefit of these input modalities. This includes:

  • Gestures that require dexterity or fine movement have alternatives that do not require high dexterity
  • Components are designed to avoid accidental activation, for example by providing undo functionality
  • Labels presented to users match corresponding object names in the code, to support activation by voice
  • Functionality that is activated by movement can also be activated through user interface components
  • Buttons, links, and other active components are large enough to make them easier to activate by touch

Understandable

Text is readable and understandable

Content authors need to ensure that text content is readable and understandable to the broadest audience possible, including when it is read aloud by text-to-speech. Such content includes:

  • Identifying the primary language of a web page, such as Arabic, Dutch, or Korean
  • Identifying the language of text passages, phrases, or other parts of a web page
  • Providing definitions for any unusual words, phrases, idioms, and abbreviations
  • Using the clearest and simplest language possible, or providing simplified versions
Content appears and operates in predictable ways

Many people rely on predictable user interfaces and are disoriented or distracted by inconsistent appearance or behavior. Examples of making content more predictable include:

  • Navigation mechanisms that are repeated on multiple pages appear in the same place each time
  • User interface components that are repeated on web pages have the same labels each time
  • Significant changes on a web page do not happen without the consent of the user
Users are helped to avoid and correct mistakes

Forms and other interactions can be confusing or difficult to use for many people, and as a result, they may be more likely to make mistakes. Examples of helping users to avoid and correct mistakes include:

  • Descriptive instructions, error messages, and suggestions for correction
  • Context-sensitive help for more complex functionality and interaction
  • Opportunity to review, correct, or reverse submissions if necessary

Robust

Content is compatible with current and future user tools

Robust content is compatible with different browsers, assistive technologies, and other user agents. Examples of how this can be achieved include:

  • Ensuring markup can be reliably interpreted, for instance by ensuring it is valid
  • Providing a name, role, and value for non-standard user interface components

Guidelines

Web Content Accessibility Guidelines (WCAG) explain how to make web content more accessible to people with disabilities and are developed through the W3C process in cooperation with individuals and organizations around the world. The goal is to provide a single shared standard for web content accessibility that meets the needs of individuals, organizations, and governments internationally.

WCAG is primarily intended for:

  • Web content developers (page authors, site designers, etc.)
  • Web authoring tool developers
  • Web accessibility evaluation tool developers
  • Others who want or need a standard for web accessibility, including mobile accessibility

The Brightree UI style guides contains a checklist that product teams can follow in their effort to align their product with WCAG 2.0 508 compliance.

Design Guidelines

Following are some basic guidelines to follow to deliver designs accessible to people with disabilities and help meet Web Content Accessibility Guidelines (WCAG) requirements. More detailed guidance can be found at https://www.w3.org/WAI/tips/designing/.

  • Provide enough contrast between foreground and background
    Foreground text needs to have enough contrast with background colors. This includes text on images, background gradients, buttons, and other elements. This does not apply for logos, or incidental text, such as text that happens to be in a photograph. The links below [BM6]provide more information on the minimum contrast ratio as required by the WCAG and how to check contrast. “Contrast ratio” is a short version of the more technically correct term “luminance contrast ratio”.
  • Don’t use color alone to convey information
    While color can be useful to convey information, color should not be the only way information is conveyed. When using color to differentiate elements, also provide additional identification that does not rely on color perception. For example, use an asterisk in addition to color to indicate required form fields, and use labels to distinguish areas on graphs.
  • Ensure that interactive elements are easy to identify
    Provide distinct styles for interactive elements, such as links and buttons, to make them easy to identify. For example, change the appearance of links on mouse hover, keyboard focus, and touch-screen activation. Ensure that styles and naming for interactive elements are used consistently throughout the website.
  • Provide clear and consistent navigation options
    Ensure that navigation across pages within a website has consistent naming, styling, and positioning. Provide more than one method of website navigation, such as a site search or a site map. Help users understand where they are in a website or page by providing orientation cues, such as breadcrumbs and clear headings.
  • Ensure that form elements include clearly associated labels
    Ensure that all fields have a descriptive label adjacent to the field. For left-to-right languages, labels are usually positioned to the left or above the field, except for checkboxes and radio buttons where they are usually to the right. Avoid having too much space between labels and fields.
  • Provide easily identifiable feedback
    Provide feedback for interactions, such as confirming form submission, alerting the user when something goes wrong, or notifying the user of changes on the page. Instructions should be easy to identify. Important feedback that requires user action should be presented in a prominent style.
  • Use headings and spacing to group related content Use whitespace and proximity to make relationships between content more apparent. Style headings to group content, reduce clutter, and make it easier to scan and understand.
  • Create designs for different viewport sizes
    Consider how page information is presented in different sized viewports, such as mobile phones or zoomed browser windows. Position and presentation of main elements, such as header and navigation can be changed to make best use of the space. Ensure that text size and line width are set to maximize readability and legibility.
  • Include image and media alternatives in your design
  • Provide a place in your design for alternatives for images and media.
    For example, you might need:
    • Visible links to transcripts of audio
    • Visible links to audio described versions of videos
    • Text along with icons and graphical buttons
    • Captions and descriptions for tables or complex graphs
  • Provide controls for content that starts automatically
    Provide visible controls to allow users to stop any animations or auto-playing sound. This applies to carousels, image sliders, background sound, and videos.

Developer Guidelines

  • Associate a label with every form control
    Use a for attribute on the label element linked to the id attribute of the form element or using WAI-ARIA attributes. In specific situations it may be acceptable to hide label elements visually, but in most cases, labels are needed to help all readers understand the required input.
  • Include alternative text for images
    alt="" for decorative images or include them in the CSS instead. Text alternatives are usually provided by those responsible for written content.
  • Identify page language and language changes
    Indicate the primary language of every page by using the lang attribute in the html tag, for example html lang="en". Use the lang attribute on specific elements when the language of the element differs from the rest of the page.
  • Use mark-up to convey meaning and structure
    Use appropriate mark-up for headings, lists, tables, etc. HTML5 provides additional elements, such as nav and aside, to better structure your content. WAI-ARIA roles can provide additional meaning, for example, using role="search" to identify search functionality. Work with designers and content writers to agree on meanings and then use them consistently.
    Help users avoid and correct mistakes; provide clear instructions, error messages, and notifications to help users complete forms on your site. When an error occurs:
    • Help users find where the problem is
    • Provide specific, understandable explanations
    • Suggest corrections...be as forgiving of format as possible when processing user input. For example, accept phone numbers that include spaces and delete the spaces as needed.
  • Reflect the reading order in the code order
    Ensure that the order of elements in the code matches the logical order of the information presented. One way to check this is to remove CSS styling and review that the order of the content makes sense.
  • Write code that Brightrees to the user’s technology
    Use responsive design to Brightree the display to different zoom states and viewport sizes, such as on mobile devices and tablets. When font size is increased by at least 200%, avoid horizontal scrolling and prevent any clipping of content. Use progressive enhancement to help ensure that core functionality and content is available regardless of technology being used.
  • Provide meaning for non-standard interactive elements
    Use WAI-ARIA to provide information on function and state for custom widgets, such as accordions and custom-made buttons. For example, role="navigation" and aria-expanded="true". Additional code is required to implement the behavior of such widgets, such as expanding and collapsing content or how the widget responds to keyboard events.

    Standard 
    
<a class="btn" href="#"&gtLink</a>
<button class="btn" type="submit"&gtButton</button>
<input class="btn" type="button" value="Input"/>
<input class="btn" type="submit" value="Submit"/>
<input class="btn" type="reset" value="Reset"/>
    Custom 
    
<div
onclick="makeMeSandwich();"
onkeypress="makeMeSandwich();"
tabindex="0"
role="button">
Make Me Sandwich.
</div>
Going outside the interface
<a target='_blank' href='sandwiches.com'>
Check all sandwiches!
<span class='sr-only'&gt(Link opens in a new tab)</span>
</a>
  • Ensure that all interactive elements are keyboard accessible
    Think about keyboard access, especially when developing interactive elements, such as menus, mouseover information, collapsible accordions, or media players. Use tabindex="0" to add an element that does not normally receive focus, such as <div> or <span>, into the navigation order when it is being used for interaction. Use scripting to capture and respond to keyboard events. tabindex="-1" allows things besides links and form elements to receive "programmatic" focus, meaning focus can be set to the element through scripting, links, etc.
  • Using device-dependent handlers
    To ensure accessibility, use either a device independent event handler (one that works with both the mouse and the keyboard) or use both mouse dependent and keyboard dependent event handlers.
    • Not a good approach...
      <div onclick="validate()">Get price</div>
    • A better approach...
      <div onkeypress="validate()" onclick="validate()">Get price</div>
    • Using Angular...
      <button (click)="validate()">Get price</button>
    For more information please refer to https://webaim.org/techniques/javascript/eventhandlers
  • Use buttons and links for specific reasons
    Screen readers handle links slightly differently than they do buttons. All links and buttons are tab-able; but pressing the Space key or Enter triggers a button, whereas pressing the Enter key only triggers a link. Use buttons to signal clickable actions, such as “download,” “sign up,” or “log out.” You may use links for less popular or less important actions. If you want something that looks and acts like a button, try to always use the button element rather than styling a link like a button. If you want the user to trigger some kind of javascript functionality by clicking, use a button. If you want a user to navigate to a new page or to a different target on the same page, use an anchor element <a>. Don’t use a <div>, <span>, or some other non-interactive element in place of a button or a link.
  • Icons need a text label
    To help overcome the ambiguity that almost all icons face, a text label must be present alongside an icon to clarify its meaning in that specific context. Even when using a standard icon, it’s often safer to include a label, especially if a slightly altered version of the icon is used to match your aesthetic preferences or constraints.
    Icon labels should always be visible, without any interaction from the user. For navigation icons, labels are particularly critical. Don’t rely on hover to reveal text labels: not only does it increase the interaction cost, but it also fails to translate well on touch devices.
  • Tables
    Data tables are used to organize data with a logical relationship in grids. Accessible tables need HTML markup that indicates header cells and data cells and defines their relationship. Assistive technologies use this information to provide context to users.
    Header cells must be marked up with <th>, and data cells with <td> to make tables accessible. For more complex tables, explicit associations may be needed using scope, id, and headers attributes.
    Tables without structural markup to differentiate and properly link between header and data cells, create accessibility barriers. Relying on visual cues alone is not sufficient to create an accessible table. With structural markup, headers and data cells can be programmatically determined by software, which means that people using screen readers can have the row and column headers read aloud as they navigate through the table. Screen readers speak one cell at a time and reference the associated header cells, so the reader doesn’t lose context.
    General best practices for tables:
    • Use the simplest table configuration possible
    • Tables should not be used for layout purposes
    • Proportional sizing, rather than absolute sizing (responsive)
    • Content can be presented in different ways (lists, cards)
    • Styling even and odd rows
    • Make sure that each separate piece of data has its cell
    • Don't use line breaks (<br> elements) to create table rows
    For detailed accessibility best practices for tables, please go to https://www.w3.org/WAI/tutorials/tables/
  • Forms
    Users typically prefer simple and short forms. Only ask users to enter what is required to complete the transaction or process; if irrelevant or excessive data is requested, users are more likely to abandon the form.
    Labeling Controls: Use the <label> element, and, in specific cases, other mechanisms (e.g. WAI-ARIA, title attribute etc.), to identify each form control.
    Best practices include:
    • Grouping Controls: Use the <fieldset> and <legend> elements to group and associate related form controls.
    • Form Instructions: Provide instructions to help users understand how to complete the form and individual form controls.
    • Validating Input: Validate input provided by the user and provide options to undo changes and confirm data entry.
    • User Notifications: Notify users about successful task completion, any errors, and provide instructions to help them correct mistakes.
    • Multi-Page Forms: divide long forms into multiple smaller forms that constitute a series of logical steps or stages and inform users about their progress.
    • Custom Controls: use stylized form elements and other progressive enhancement techniques to provide custom controls.
    If possible, forms should not be subject to a time limit to allow users to complete the form at their pace. If a time limit needs to be in place, for example, for security reasons, the user should have the option to turn it off or extend it. This restriction does not apply if the time limit is due to a live event, such as an auction or a game, or if the time to complete the form is essential for a valid submission.
    Forms can be visually and cognitively complex and challenging to use. Accessible forms are easier to use for everyone, including people with disabilities.
    • People with cognitive disabilities can better understand the form and how to complete it, as making forms accessible improves the layout structure, instructions, and feedback.
    • People using speech input can use the labels via voice commands to activate controls and move the focus to the fields that they have to complete.
    • People with limited dexterity benefit from large clickable areas that include the labels, especially for smaller controls, such as radio buttons and checkboxes.
    • People using screen readers can identify and understand form controls more easily because they are associated with labels, field sets, and other structural elements.
    For detailed guidelines on accessible forms, please see https://www.w3.org/WAI/tutorials/forms/
  • Images
    Every image needs an alternative text attribute alt. Alt text describes pictorial content in words. The alt attribute greatly helps people using assistive technologies and users of mobile devices with images turned off (to save data, for instance). Alt tags are also important for sighted readers. If your image path ever changes, your alt tag will still show up on the page, and no loss of information will occur.
    • If the image is a link: The alt text describes where the link goes. For example, a logo that links to your home page should have alt="home page" or alt="Carnegie Museums of Pittsburgh logo - home page".
    • If the image is important to the context of the page: The alt text should contain a concise description of the image that is representative within the context.
    • The description should NOT include the phrase “image of” or “picture of”. Assistive technologies already do this.
    • Don’t put line breaks in alt text. It causes suboptimal effects when read by screen readers.
    • Make sure the description of the image is useful. For example, if the image is your logo your alt should be your company name and not “logo.”
    • If the image is decorative: If the image is purely decorative, or not necessary for understanding the content of the page, use an empty tag (alt="") to instruct a screen reader to skip it. If you do not, a screen reader will read the source tag which sounds awful.
    • If the image is a complex graphic: Each needs to be addressed based upon its context and use.
    Example Code
    • Informative images
      <img src="pune.jpg" alt="Pune City map"/>
    • Decorative images: Provide a null text alternative (alt="")
      <img src="decoration.png" alt=""/>
    • SVG usage in img
      <img src='/images/blue-triangle.svg' role='image' alt='Blue Triangle'/>
    • Inline SVG 
      
<svg aria-labelledby="title">
<title id="title" lang="en">Bar chart</title>
<desc>Bar chart showing company sales by country, in millions of dollars (US).</desc>
<g>
<rect x="0" y="0" width="100" height="50" fill="red" />
</g>
</svg>
    • Iconfont 
      
<i class="d-bicycle" aria-hidden="true" title="Time to destination by bike"></i>
<span class="sr-only">Time to destination by bike:</span>
  • WAI-ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications)
    WAI-ARIA attributes only affect the information exposed by the browser's accessibility APIs (where screen readers get their information from). WAI-ARIA doesn't affect webpage structure, the DOM, etc., although the attributes can be useful for selecting elements by CSS.
    Roles define what an element is or does. Many of these are so-called landmark roles, which largely duplicate the semantic value of HTML5 structural elements e.g. role="navigation" (<nav>) or role="complementary" (<aside>), but there are also others that describe different pages structures, such as role="banner", role="search", role="tabgroup", role="tab", etc.
    Four categories of WAI-ARIA roles are:
    • Landmark: essentially duplicates the semantic value of HTML5 structural elements, such as role="navigation" (<nav>) or role="complementary" (<aside>), but there are also others that describe different pages structures, such as role="banner", role="search", role="tabgroup", role="tab", etc., which are commonly found in UIs.
    • Document: generally used in complex composite widgets or applications, the document role can inform assistive technologies to switch context to a reading mode: The document role tells assistive technologies with reading or browse modes to use the document mode to read the content contained within this element.
    • Widget: used to describe what are often javascript-based interfaces, widgets are discrete user interface objects with which the user can interact. Widget roles map to standard features in accessibility APIs. When the user navigates an element assigned any of the non-abstract subclass roles of widget, assistive technologies that typically intercept standard keyboard events SHOULD switch to an application browsing mode, and pass keyboard events through to the web application. The intent is to hint to certain assistive technologies to switch from normal browsing mode into a mode more appropriate for interacting with a web application; some user agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document, and this native behavior prevents the use of these keys by a web application.
    • Properties: define properties of elements, which can be used to give them extra meaning or semantics. As an example, aria-required="true" specifies that a form input needs to be filled in to be valid, whereas aria-labelledby="label" allows you to put an ID on an element, then reference it as being the label for anything else on the page, including multiple elements, which is not possible using <label for="input">. As an example, you could use aria-labelledby to specify that a key description contained in a <div> is the label for multiple table cells, or you could use it as an alternative to image alt text — specify existing information on the page as an image's alt text, rather than having to repeat it inside the alt attribute. You can see an example of this at Text alternatives.
    • States: special properties that define the current conditions of elements, such as aria-disabled="true", which specifies to a screenreader that a form input is currently disabled. States differ from properties in that properties don't change throughout the lifecycle of an app, whereas states can change, generally programmatically via JavaScript.

Tools and Resources

https://material.angular.io/cdk/a11y
http://wave.webaim.org/
https://developers.google.com/web/tools/chrome-devtools/accessibility/reference
https://github.com/collections/web-accessibility
http://www.freedomscientific.com/Downloads/#JAWS
https://www.3pillarglobal.com/insights/accessibility-testing-using-jenkins-google-accessibility-developer-tools
https://github.com/liip/TheA11yMachine

ARIA

http://whatsock.com/training/matrices
https://github.com/accdc/visual-aria
https://www.w3.org/TR/wai-aria-1.1/
https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics