Introduction to accessibility
What is accessibility?
Accessibility is equal treatment and equal opportunity for all. In Canada, it's creating communities, workplaces and services that enable everyone to participate fully in society without barriers.1 We tend to think of accessibility as a target for people with disabilities, but the practice of making something accessible benefits everyone. For example, accessibility could benefit someone who's learning a new language, has a slow internet connection, working in a loud space or looking at a small mobile screen.
Why is it important?
The web is now our primary source of information. We rely on it for online banking, communication, booking vacations, social media, shopping, watching TV, reading the news and applying for jobs. It has fundamentally changed the way we interact with the world around us. Web accessibility is not only an ethical standard, it's a legal obligation closely tied to a business' reputation and corporate responsibilty.
Facts and figures:
More than 6.2 million Canadians live with some form of disability
- An estimated 1 in 5 Canadians aged 15 years and over are living with some form of disability that affects their level of freedom, independence or quality of life.2
- Many Canadians with disabilities rely on assistive technologies - more than 8 in 10 with a disability used some type of assistive aid.3
Growing research efforts underway to improve accessibility
- At the start of 2020, Accessibility Standards Canada launched a program that funds research projects aiming to identify, prevent and eliminate accessibility barriers.4
- The Accessible Technology Program co-funds innovative projects that develop new assistive and adaptive digital devices and technologies.5
Businesses that are accessible have a competitive advantage
- The Ontario marketplace is becoming more diverse, with $9.6 billion in new retail spending from improved accessibility.6
- It is estimated that by 2031 the income controlled by people with disabilities and those at risk of disability (above the age of 55) will reach a staggering $536 billion.7
Accessibility for Ontarians with Disability Act
The Co-operators is committed to meeting the Accessibility for Ontarians with Disabilities Act (“AODA”) and by extension the Web Content Accessibility Guidelines 2.0, level AA (WCAG 2.0 AA). The Co-operators qualifies under the AODA as business/non-profit organization with 50+ employees. The websites under The Co-operators control, meaning we have direct or contractual control over the website's appearance, functionality and content, must meet these accessibility requirements. Web accessibility ensures that people with disabilities can perceive, understand, navigate, interact with, and contribute to the applications that are created. This means all The Co-operators pages should be perceivable, operable, understandable, and robust.
Please read more about The Co-operators accessibility.
WCAG 2.0 is divided into twelve (12) guidelines under four (4) principles:
The above principle divides into 12 principles having thirty-eight (38) criterion to follow as defined in Digital Web Standards. A brief description about key requirements that could affect web accessibility and reflect a couple of criterion as listed in Digital Web Standards are listed below:
|UI elements labeled||Assistive technologies rely on programmatically-set text to read it back to the user. Examples of UI elements are: navigation menus, buttons, links, form fields, informational images, etc. They all need to be labeled to be read back to the user.
Note: decorative images shouldn’t be labeled or read back, in fact they must be hidden from assistive technology.
|Language Specified||The language of pages must be specified:
This is required to help assistive technologies (like screen readers) decide which language to use when reading back pages’ content: text, images of text, labels, tooltips, sounds, video captions / subtitles, page and screen titles.
The language of parts must be specified:
Content fragments that should always be read in a certain language regardless of the default language on the device should be specified so.
|Content structured semantically||All titles for pages / screens are unique & representative of the content:
Titles help users orientate themselves within the website. The title is often the first thing users hear or see and acts as a confirmation of what page they have arrived at.
Use semantic elements to indicate content structure:
To indicate structure, use semantic elements - headings, links, lists, tables, etc. - when available. Support varies between the operating systems and different version. Users rely on this information to navigate the website.
The reading & focus order is logical:
The order must be logical, so users of assistive technology can follow the natural flow of the page - usually from top to bottom, left to right (though some languages are right to left).
Interactive content has different visual treatment:
Interactive elements - links, buttons, swipe areas, etc. - must be clearly distinguishable from the static content.
|UI & assistive technologies||The navigation/reading model changes dramatically when assistive technologies (ATs) are turned on. The following requirements are the absolute minimum for the screen reader experience.
UI elements have visible focus:
Interactive UI elements (buttons, links, menus, etc.) take focus when swiped to / tapped and it is clearly visible.
Functionality is not lost with ATs on:
Because the navigation / reading model is different it is important that functionality does not get diminished. Regular functions like activating buttons, opening/closing menus, etc. are fully functional with assistive technologies turned on.
Focus is managed:
Focus should not get lost or reset to the top when interacting with UI elements (buttons, links, menus, etc.).
|State changes & errors||UI changes must be indicated both visually and have a text-equivalent. Multisensory information ensures that people with different disabilities can perceive the change.
Meaning is not conveyed through colour alone:
Colour alone is not sufficient to convey meaning or a state change. For example, using the green color to indicate that a form field is valid.
The current state is indicated:
It is very common for UI elements to have 2 (or more states), e.g. on/off buttons. The current state should be indicated both visually and in text.
Provide error messages in plain language and move focus to them:
Provide error messages in plain language (do not use jargon or error codes). Also, ensure focus is programmatically moved to the error messages.
|Accessible colours||Ensure sufficient colour contrast:
At a minimum, use the WCAG 2.0 Level AA contrast ratio of at least 4.5:1. However, it is strongly recommend aiming for a higher ratio of 7:1 given the mobile context: glossy and / or smudge screens, sun glare, lower quality screens on older phones, etc.
Use colour blind friendly colours:
Avoid colours that could be perceived as similar by people with colour blindness. Red & green is a well-known example.
No other legislations with specific requirements for web that are similar to the AODA for other provinces.
Public websites, web-based mobile apps, and content must meet the standards. Internal websites and content posted before January 1st, 2012, are not required. If asked, content must be made available in an accessible format to the requester such as large print or braille. To adhere with WCAG2.0, level AA, The Co-operators will extend and include commitment to our partners and vendors to ensure all websites meet WCAG 2.0, level AA.
If compliance is not possible
If tools and software (e.g. CMS, framework) used to develop the website predates WCAG 2.0, update or repair the products to support accessibility. If not possible, make sure to use software that supports accessibility in the next website refresh.
Some content might not be possible to be posted in an accessible format (e.g. online maps, complex diagrams). In such cases, the content can be posted, but an alternate accessible format must be provided upon request.
|By 01-01-2014||All new public websites, new web-based applications, significantly updated websites and any web content (information found on a webpage or web application. Includes text, images, forms and sounds) posted after January 1st 2012 must meet WCAG 2.0 Level A compliance. A new site is a site with a new web address or a significantly new look and feel. A website is not considered new if a new page or link was added. A significantly updated website means keeping the same web address, but making changes such as: new look and feel, how users navigate, major update and change to the content of the website.|
|By 31-12-2014||Accessibility compliance reports every 3 years (2014, 2017, 2020, ... etc.).|
|By 01-01-2021||All public websites, web-based applications and content posted after January 1st 2012 must meet WCAG 2.0 Level AA (exception: 1.2.4-live captions and 1.2.5-pre-recorded audio descriptions) compliance.|
The WCAG 2.0 criterial covers a range of specifications and should be reviewed at every stage.
Keep accessibility in mind when designing the user experience and user interface. Choice of input field types, colour contrast, natrual user behavior, etc.
Accessibility should be considered at the very beginning in content/design/wireframes
It is important to communicate with the development and quality assurance team to:
- Outline accessibility requirements and expectations.
- Ensure developers are familiar with WCAG 2.0, provide examples and documentation.
- Outline testing plan according to the testing strategy.
It is important to test the product against each of the WCAG 2.0 criteria. To meet the desired level of conformity (generally Level AA).
Using the device’s built-in assistive technology. Test using popular assistive technologies (e.g. NVDA) on multiple platforms.
Ask customers or people with disabilities to test and navigate through the website or application before launch. Collect feedback and assess if any improvements are needed.
Keep a log of accessibility issues and if the issue has been resolved. Also, log completed work to conform to certain WCAG 2.0 criteria. This should be done for every page/complete process, logged in the accessibility checklist excel workbook provided. The log will also allow us to keep track of accessibility issues and produce a conformance claim/statement if required.
The checklist keeps track of:
- Overview of accessibility testing for the whole project (“Index” sheet)
- Specific accessibility testing results per page:
Content writers, BAs, BSAs, designers, developers and QAs should all contribute to this log. Thus a centralized place to store the log with version control is recommended.
Accessibility is a core activity to our projects and development process where everyone has a responsibility to fulfill accessibility WCAG 2.0, level AA requirements. The following is just a short-list of must-have accessibility responsibilities:
- Project management: accessibility should be included in scope for every sprint, plan for it.
- Content management: craft descriptive labels and account for translation.
- Design: ensure colours meet the minimum colour contrast ratio.
- Web Development: prescribe the keyboard interaction and provide focus states.
- QA: ensure robust coverage and run testing on a regular basis.
Use the following link for a complete responsibilities matrix: w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown
Keep accessibility in mind when designing the user experience (UX) and user interface (UI). Choice of input field types, colour contrast, natural user behavior, etc. Accessibility should be considered at the very beginning in content/ design/ wireframes etc., by defining responsibilities for the project.