info@qaconsultants.com (416) 238-5333

WCAG 2.0 Level A & Level AA Analysis of Insurance Companies

Keyboard with the words accessibility and WCAG
Introduction

QA Consultants, an industry leader and subject-matter expert in Web Content Accessibility Guidelines (WCAG) Conformance Services, performed an analysis of the websites of a sampling of popular Canadian Insurance Companies, testing the main “home” page of their websites for compliance with the WCAG 2.0 Level A and Level AA Principles, Guidelines and Success Criteria to see where they stand today. 

With the quickly-approaching deadline of January 1, 2021, mandated by the Accessibility for Ontarians with Disabilities Act (AODA) here in Ontario, Canada, where all public-facing websites of companies must be WCAG 2.0 Level A and Level AA compliant, all of our Clients who have Customers in Ontario who may visit their website are urgently working towards meeting this requirement.

When it comes to WCAG 2.0 Level A and Level AA compliance, there isn’t a “50%” or “70%” or “99%” compliant measure. It is either compliant (100%) or not compliant (<100%), as people with accessibility needs don’t only need to be able to view a certain percentage of your website which is compliant. As such, it is absolutely critical for all organizations to ensure that they test their websites to ensure that they are compliant, and they address any/all WCAG defects which may exist.

The results of our WCAG analysis of the Insurance industry here in Canada is quite shocking and shows that they still have a lot of work to do. 

Below is a summary of QA Consultants’ WCAG conformance testing approach which was used for this analysis.

QA Consultants Accessibility and WCAG Conformance Testing Approach

  • QA Consultants Accessibility and WCAG Conformance Testing Approach include:

o   Industry Leading Best Practice Approach based on Proprietary Test Cases and Testing Techniques developed over years of performing Accessibility Conformance Testing engagements

  • Detailed Business and Technical Analysis (including Source Code Analysis) of:

o   Content Items

o   Content Components

o   Content Design & Structure

o   Content within the Content Items

  • Perform in-depth Page-by-Page (Screen-by-Screen) Analysis via a combination of methods, including:

o   Manual Testing and Analysis Practices

o   Technology-Assisted Testing

o   Automated Testing Tools

  • WCAG Conformance Testing and Reporting based on the Website Accessibility Conformance Evaluation Methodology (WCAG-EM)

Below is a summary of the results of our WCAG 2.0 Level A and Level AA testing of a sampling of popular Canadian Insurance Companies. 

Please note that the names of these organizations have not been published. If you would like to know where your Insurance Company has landed in this analysis, please feel free to reach out to QA Consultants. Click here for our contact information.

Overall Compliance with the WCAG 2.0 Level A and Level AA Principles, Guidelines and Success Criteria

WCAG 2.0 Level A & Level AA Guidelines & Success Criteria

QA Consultants’ WCAG 2.0 Level A and Level AA Test Results show that not one of the Insurance Companies that were included in this analysis was compliant with the WCAG 2.0 Level A and Level AA Principles, Guidelines and Success Criteria on the main “home”’ page of their websites. This was a terribly unfortunate finding as this indicates that people who have accessibility needs would not be able to appropriately and adequately use their websites and have the same ability to perceive, operate and understand their web content as a person without accessibility needs.

The analysis showed that on average, the main “home” pages of the Insurance company websites Passed ~14 (36%), Failed ~13 (35%), and had ~11 (29%) as Not Applicable, of the 38 WCAG 2.0 Level A and Level AA Principles, Guidelines and Success Criteria.  There was an average of 41 WCAG Defects that were found on each Insurance Company main “home” page.

Definitions

    • PASS – A Pass in the context of this analysis means that the webpages which were tested fulfilled and/or satisfied all of the Success Criteria as outlined for the applicable WCAG 2.0 Level A and Level AA Principles and Guidelines.
    • FAIL – A Fail in the context of this analysis means that the webpages which were tested did not fulfil and/or satisfy one or more of the Success Criteria as outlined for the applicable WCAG 2.0 Level A and Level AA Principles and Guidelines. Defects were captured for every instance of failure for each Success Criteria.
    • N/A An N/A or “Not Applicable” in the context of this analysis refers to WCAG 2.0 Level A and Level AA Principles and Guidelines which were not applicable in the webpages which were tested. The WCAG 2.0 Level A and Level AA Principles and Guidelines are based on the actual content that is existent on a webpage. For example, Guideline 1.2 Time-based Media: Provide alternatives for time-based media, which includes three Level A and two Level AA Success Criteria, are specific to audio and video. If there isn’t any audio or video on a specific webpage, then those WCAG 2.0 Level A and Level AA Guidelines and Success Criteria would be categorized as N/A (Not Applicable).

 

Compliance with the WCAG 2.0 Level A and Level AA Principle 1 – Perceivable

As per the W3C website, Principle 1 – Perceivable means, “Information and user interface components must be presentable to users in ways they can perceive.”

Principle 1 – Perceivable has the following Guidelines for Level A and Level AA:

  • Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
  • Guideline 1.2 Time-based Media: Provide alternatives for time-based media.
  • Guideline 1.3 Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
  • Guideline 1.4 Distinguishable: Make it easier for users with disabilities to see and hear content including separating foreground from background.

WCAG 2.0 Level A & Level AA for Principle 1 - Perceivable

QA Consultants’ WCAG 2.0 Level A and Level AA Test Results show that on average, the main “home” pages of the Insurance company websites Passed 28%, Failed 29%, and had 43% as Not Applicable, of the WCAG 2.0 Level A and Level AA Guidelines and Success Criteria for Principle 1 – Perceivable.

Below are the details for each of the Guidelines for Principle 1 – Perceivable.

WCAG 2.0 Level A & Level AA Guidelines for Principle 1 - Perceivable NA FAIL PASS

As can be seen in the table above, with the exception of Guideline 1.2 – Time-based Media which was not applicable for all of the Insurance main “home” page web pages that were tested (as none of them had Video or Audio), all of the other Guidelines had Failed Success Criteria.

The results showed that the following Success Criteria were the strongest areas:

  • 1.3.2 Meaningful Sequence [Level A] The majority of Insurance Companies Passed
  • 1.3.3 Sensory Characteristics [Level A] ALL Insurance Companies Passed
  • 1.4.5 Images of Text [Level AA] The majority of Insurance Companies Passed

The results showed that the following Success Criteria were the biggest problem areas:

  • 1.1.1 Non-text Content [Level A] The majority of Insurance Companies Failed
  • 1.3.1 Info and Relationships [Level A] The majority of Insurance Companies Failed
  • 1.4.3 Contrast (Minimum) [Level AA] The majority of Insurance Companies Failed

SUCCESS CRITERIA FOCUS #1:  1.1.1 Non-text Content [Level A]

WCAG Definition

Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Success Criteria:  1.1.1 Non-Text Content [Level A]:  All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the situations listed below.

  • Controls, Input: If non-text content is a control or accepts user input, then it has a name that describes its purpose.
  • Time-Based Media: If non-text content is time-based media, then text alternatives at least provide descriptive identification of the non-text content.
  • Test: If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.
  • Sensory: If non-text content is primarily intended to create a specific sensory experience, then text alternatives at least provide descriptive identification of the non-text content.
  • CAPTCHA: If the purpose of non-text content is to confirm that content is being accessed by a person rather than a computer, then text alternatives that identify and describe the purpose of the non-text content are provided, and alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities.
  • Decoration, Formatting, Invisible: If non-text content is pure decoration, is used only for visual formatting, or is not presented to users, then it is implemented in a way that it can be ignored by assistive technology.

What you need to know

ALT Attribute

ALT texts (text alternatives) are words that show up in place of an image. This is sometimes the case for users with visual accessibility needs who often use screen readers to read the ALT text aloud. ALT text should describe the image; if the image is a company logo then the company name would work.

What you need to do

  • All images need an ALT attribute assigned to them, regardless of image type or if they have a TITLE attribute.
  • All images that are used purely for decorative or formatting reasons should have a blank ALT attribute or be implemented as CSS backgrounds.
  • Image ALT shouldn’t be duplicated, but instead be unique to the image, unless it’s a purely decorative image in which case a blank ALT attribute is fine.
  • Image ALT shouldn’t be the same as the filename of the image.
  • All linked images have descriptive alternative text.
  • Equivalent alternatives to complex images are provided in context or on a separate linked page.
  • Form buttons have a descriptive value.
  • Form inputs have associated text labels.
  • Embedded multimedia is identified via accessible text.
  • Frames and iframes are appropriately titled.

Defect Example

Many examples were found where decorative images, or images which are present only for decoration and not to communicate any specific information, had a populated ALT text value.  All decorative images should either have a blank ALT text value, or they should be implemented as CSS backgrounds. 

The reason that this is important is that users that utilize assistive technology for websites will have the image ALT text read aloud to them. If the image is purely there for decorative purposes, when the ALT text is read aloud to the user, it won’t make sense and may confuse the user.

Decorative images with a populated ALT text value would be considered as a violation of Success Criteria:  1.1.1 Non-Text Content [Level A].

Compliance with the WCAG 2.0 Level A and Level AA Principle 2 – Operable

As per the W3C website, Principle 2 – Operable means, “User interface components and navigation must be operable.”

Principle 2 – Operable has the following Guidelines for Level A and Level AA:

  • Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
  • Guideline 2.2 Enough Time: Provide users enough time to read and use content.
  • Guideline 2.3 Seizures: Do not design content in a way that is known to cause seizures.
  • Guideline 2.4 Navigable: Provide ways to help users navigate, find content, and determine where they are.

WCAG 2.0 Level A & Level AA for Principle 2 - Operable

QA Consultants’ WCAG 2.0 Level A and Level AA Test Results show that on average, the main “home” pages of the Insurance company websites Passed 36%, Failed 43%, and had 21% as Not Applicable, of the WCAG 2.0 Level A and Level AA Guidelines and Success Criteria for Principle 2 – Operable.

Below are the details for each of the Guidelines for Principle 2 – Operable.

WCAG-2.0-Level-A-Level-AA-Guidelines-for-Principle-2-Operable

As can be seen in the table above, with the exception of Guideline 2.3 – Guideline 2.3 – Seizures and Physical Reactions which was not applicable for all of the Insurance main “home” page web pages that were tested (as none of them had any content that flashes), all of the other Guidelines had Failed Success Criteria.

The results showed that the following Success Criteria were the strongest areas:

  • 2.1.2 No Keyboard Trap [Level A] ALL Insurance Companies Passed
  • 2.4.2 Page Titled [Level A] The majority of Insurance Companies Passed
  • 2.4.5 Multiple Ways [Level AA] The majority of Insurance Companies Passed
  • 2.4.6 Heading and Labels [Level AA] The majority of Insurance Companies Passed

The results showed that the following Success Criteria were the biggest problem areas:

  • 2.1.1 Keyboard [Level A] ALL Insurance Companies Failed
  • 2.2.2 Pause, Stop, Hide [Level A] All Insurance Companies Failed (who had this Success Criteria applicable)
  • 2.4.1 Bypass Blocks [Level A] The majority of Insurance Companies Failed
  • 2.4.3 Focus Order [Level A] The majority of Insurance Companies Failed
  • 2.4.4 Link Purpose (In Context) [Level A] The majority of Insurance Companies Failed
  • 2.4.7 Focus Visible [Level AA] The majority of Insurance Companies Failed

SUCCESS CRITERIA FOCUS #2:  2.1.1 Keyboard [Level A]

WCAG Definition

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.

Success Criteria:  2.1.1 Keyboard [Level A]: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints.

  • Note 1: This exception relates to the underlying function, not the input technique. For example, if using handwriting to enter text, the input technique (handwriting) requires path-dependent input but the underlying function (text input) does not.
  • Note 2: This does not forbid and should not discourage providing mouse input or other input methods in addition to keyboard operation.

What you need to know

All content should be accessible and operable via a keyboard. The user should be able to get to all content elements via the usage of a keyboard only (with the exceptions noted in the Success Criteria definition above).

What you need to do

  • All page functionality is available using the keyboard, unless the functionality cannot be accomplished in any known way using a keyboard (e.g., freehand drawing).
  • Page-specific shortcut keys and accesskeys (accesskey should typically be avoided) do not conflict with existing browser and screen reader shortcuts.

Defect Example

Many examples were found where the content was not accessible via the keyboard only. For example, a “Search” input field was not accessible by the keyboard only and therefore required the user to only be able to access it with a mouse. 

The reason this is important is because all users should be able to access all content on a website regardless of their accessibility needs. Making all content accessible via usage of the keyboard only makes this possible. Having content that is only accessible via a mouse means that not all users will be able to access that content.

Content elements which are not accessible via the keyboard only would be considered as a violation of Success Criteria:  2.1.1 Keyboard [Level A].

Compliance with the WCAG 2.0 Level A and Level AA Principle 3 – Understandable

As per the W3C website, Principle 3 – Understandable means, “Information and the operation of user interface must be understandable.”

Principle 3 – Understandable has the following Guidelines for Level A and Level AA:

  • Guideline 3.1 Readable: Make text content readable and understandable.
  • Guideline 3.2 Predictable: Make Web pages appear and operate in predictable ways.
  • Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.

WCAG 2.0 Level A & Level AA Guidelines for Principle 3 - Understandable

QA Consultants’ WCAG 2.0 Level A and Level AA Test Results show that on average, the main “home” pages of the Insurance company websites Passed 53%, Failed 22%, and had 25% as Not Applicable, of the WCAG 2.0 Level A and Level AA Guidelines and Success Criteria for Principle 3 – Understandable.

Below are the details for each of the Guidelines for Principle 3 – Understandable.

As can be seen in the table above, all of the Guidelines had Failed Success Criteria.

The results showed that the following Success Criteria were the strongest areas:

  • 3.1.1 Language of Page [Level A] The majority of Insurance Companies Passed
  • 3.2.1 On Focus [Level A] The majority of Insurance Companies Passed
  • 3.2.2 On Input [Level A] The majority of Insurance Companies Passed
  • 3.2.3 Consistent Navigation [Level AA] ALL Insurance Companies Passed
  • 3.2.4 Consistent Identification [Level AA] The majority of Insurance Companies Passed
  • 3.3.1 Error Identification [Level A] The majority of Insurance Companies Passed
  • 3.3.3 Error Suggestion [Level AA] The majority of Insurance Companies Passed

The results showed that the following Success Criteria were the biggest problem areas:

  • 3.1.2 Language of Parts [Level AA] The majority of Insurance Companies Failed
  • 3.3.2 Labels or Instructions [Level A] The majority of Insurance Companies Failed

SUCCESS CRITERIA FOCUS #3:  3.1.2 Language of Parts [Level AA]

WCAG Definition

Guideline 3.1 Readable: Make text content readable and understandable.

Success Criteria:  3.1.2 Language of Parts [Level AA]: The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.

What you need to know

Assistive technologies rely on the language settings of content to be able to interpret it appropriately for the user. The language of content can be set both at the page level, as well as at various levels throughout the content. If the language changes throughout the content, the language should be set at those levels accordingly.

What you need to do

  • Make sure the language of page content that is in a different language is identified using the lang attribute (e.g., <blockquote lang=”es”>).

Defect Example

Many examples were found where webpages had content with differing languages on the same page, but the language setting was only applied for the main page and not applied at the various levels where it changed. For example, the main “home” page had its language set to English, but there were parts of the webpage which had content in French without those specific areas having the language set accordingly. 

The reason this is important is because the assistive technologies will not be able to appropriately interpret the language where it has changed from the main page setting, and therefore will not be able to communicate that content appropriately to the user.   

Content elements which don’t have their language setting applied appropriately throughout the webpage would be considered as a violation of Success Criteria:  3.1.2 Language of Parts [Level AA].

Compliance with the WCAG 2.0 Level A and Level AA Principle 4 – Robust

As per the W3C website, Principle 4 – Robust means, “Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.”

Principle 4 – Robust has the following Guideline for Level A and Level AA:

  • Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

WCAG 2.0 Level A & Level AA For Principle 4 - Robust

QA Consultants’ WCAG 2.0 Level A and Level AA Test Results show that on average, the main “home” pages of the Insurance company websites Failed 100% of the WCAG 2.0 Level A and Level AA Guidelines and Success Criteria for Principle 4 – Robust.

Below are the details for each of the Guidelines for Principle 4 – Robust.

WCAG 2.0 Level A & Level AA For Principle 4 - Robust bar chart

As can be seen in the table above, the Guideline has Failed Success Criteria.

The results showed that the following Success Criteria were the biggest problem areas:

  • 4.1.1 Parsing [Level A] All Insurance Companies Failed
  • 4.1.2 Name, Role, Value [Level A] All Insurance Companies Failed

SUCCESS CRITERIA FOCUS #4:  4.1.2 Name, Role, Value [Level A]

WCAG Definition

Guideline 4.1 Compatible: Maximize compatibility with current and future user agents, including assistive technologies.

Success Criteria:  4.1.2 Name, Role, Value [Level A]: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

  • Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

What you need to know

All form elements on a webpage must have their appropriate attributes and use correct markup. If this is not done correctly, assistive technologies will read the element incorrectly. This will make the website confusing for users with accessibility needs.

What you need to do

  • Make sure all HTML elements have appropriate attributes assigned.
HTML element Role Name Value
<a> link ‘title’ attribute, text within <a> element or ‘alt’ attribute if image link. Concatenated if both text and image ‘alt’ attribute are provided ‘href’ attribute
<button> push button text inside <button> element or ‘title’ attribute
<fieldset> grouping text inside <legend> element within fieldset element
<input type = “button”, “submit”, or “reset”> push button ‘value’ attribute
<input type = “image”> push button ‘alt’ attribute or ‘title’ attribute
<input type = “text”> editable text <label> element associated with it or ‘title’ attribute ‘value’ attribute
<input type = “password”> editable text <label> element associated with it or ‘title’ attribute value is purposefully hidden
<input type=”file”> editable text <label> element associated with it or ‘title’ attribute ‘value’ attribute
<input type=”checkbox”> checkbox <label> element associated with it or ‘title’ attribute
<input type=”radio”> radio button <label> element associated with it or ‘title’ attribute
<select> list box <label> element associated with it or ‘title’ attribute <option> element with ‘selected’ attribute set to “selected”
<textarea> editable text <label> element associated with it or ‘title’ attribute text within <textarea> element

Defect Example

Many examples were found where webpages had used images with a link which appeared as a button, instead of using the appropriate HTML button control. For example, an image that looked like a button but was actually a hyperlink with the image of a button was used to direct a user to a specific webpage upon clicking. The appropriate approach would have been to utilize an HTML button control for this purpose.

The reason this is important is because assistive technologies will interpret this usage inappropriately which will result in a confusing experience for the user (interpreted as an image or link instead of a button). Buttons are expected to be triggered using the <SPACE BAR> or <ENTER> key, while links are expected to be triggered using the <ENTER> key. 

Where possible, it is recommended to use native HTML buttons (<button>, <input type=”button” />,  <input type=”submit” />, <input type=”reset” /> and <input type=”image” />), as native HTML buttons are more widely supported by older user agents and assistive technology. Native HTML buttons also support keyboard and focus requirements by default, without the need for additional customization.

Using content elements that replace already existing HTML controls, such as using images with links in order to simulate the actions of a button (which an HTML button control already exists), would be considered as a violation of Success Criteria:  4.1.2 Name, Role, Value [Level A].

Conclusion

In conclusion, as this analysis shows, the Insurance Industry here in Canada still has a lot of work to do in order to meet the January 1, 2021 deadline of being WCAG 2.0 Level A and Level AA compliant. On average we’ve seen 35% of the WCAG 2.0 Level A and Level AA Principles, Guidelines and Success Criteria Fail for the main “home” webpages of their websites which is troubling. This, of course, is specifically for their main “home” webpage where it’s possible that some attention may have already been paid from a WCAG perspective, given that it is probably their highest-trafficked webpage. It is very likely that things may be worse on other less visited and older pages.

It’s possible that some of these companies may have felt safe from a WCAG perspective given the following:

  • Their usage of a Content Management System which states that their platforms are WCAG 2.0 Level A and Level AA compliant right “out of the box”.
  • Usage of Automated WCAG Scanning Tools which state that they can identify any/all WCAG 2.0 Level A and Level AA compliance issues. Some which also say they can fix these issues in an automated fashion.

In reality, it is impossible to have WCAG 2.0 Level A and Level AA compliant content which is created via an automated manner. Extensive human judgement and intervention is required in order to make web content WCAG 2.0 Level A and Level AA compliant, and also to test and verify that it is indeed compliant. Please see the W3C website for further details: What Evaluation Tools Can Do and Can Not Do.

QA Consultants is an industry leader in WCAG Conformance Services, with:

  • Specialized WCAG Level A, AA and AAA Accessibility (WCAG) Conformance Practice since 2013
  • Deep pool of Accessibility (WCAG) Conformance QA and Consulting (SME) Specialists
  • Strong knowledge and understanding of the WCAG 2.0+2.1 Principles, Guidelines, Success Criteria and Techniques
  • Extensive experience delivering WCAG Conformance services to various Clients including Government, Fortune 500, Financial Institutions, Web Design Agencies, etc.
  • Proven methodology for bringing web content items such as webpages, documents (including PDF, MS Word, PowerPoint, etc.) audio and video up to WCAG Conformance
  • Advanced and industry-leading testing techniques which optimize efforts and timelines via the usage of manual, computer-assisted and automated methods
  • Detailed Reporting that is consultative in nature enabling concise and focused code changes to address Defects and ensure Client WCAG Conformance
  • Specialized solution model which guides clients through the WCAG Conformance process, including working with Creative and Web Design Agencies, Development Teams, etc.

QA Consultants offers the following WCAG Conformance Solutions and Services:

  • Accessibility (WCAG) Audit and Detailed Testing Services
  • Screen Reader Audit (WCAG-based and/or User Experience for User with Accessible needs)
  • Accessibility (WCAG) Content Remediation Services

o   Project Management

o   Accessibility (WCAG) SME Consulting

o   Remediation Delivery (Test Cycle-based, Project-based, On-Demand)

  • Webpages, Documents (PDF, MS Word, PPT, etc.), Video/Audio (Transcript, Captions, etc.)
  • Accessibility (WCAG) Ongoing SDLC Project Support
  • Accessibility (WCAG) Automation/Tool Report Consulting (ex. SiteImprove, Compliance Sheriff, etc.)

o   Report Review/Analysis, Explanation, Consulting on Prioritized Actions, etc.

  • Accessibility (WCAG) Education and Training Services
  • Cross-Device (Desktop, Mobile, etc.) and Cross-Platform (ex. iOS, Windows, Android, etc.)

Please feel free to reach out to QA Consultants (https://qaconsultants.com/contact-us/) for your Accessibility (WCAG) Conformance needs.  We will partner with you to bring your web content up to WCAG 2.0 Level A/AA/AAA compliance.

References

W3C Copyright Notice

The following Copyright statement has been included as required by the W3C Document License (https://www.w3.org/Consortium/Legal/2015/doc-license):

Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). This software or document includes material copied from or derived from “Web Content Accessibility Guidelines (WCAG) 2.0” located at URL: https://www.w3.org/TR/WCAG20/.

Additional Information

QA Consultants Accessibility (WCAG) Conformance Practice Testimonial by Logibec:

QA Consultants – Test Talk Episode 3: Accessibility Testing & Compliance: