Summary: Accessibility compliance is governed by laws (Section 508 of the ADA in the US and the soon to be ratified European Accessibility Act). Web developers look to WCAG 2.0 of the W3 standards organization and typically aim at “AA” compliance. This article explores quality from an accessibility standpoint and points to areas of better compliance that go beyond the “getting by” approach.
Web Accessibility efforts are plagued with a “getting by” approach to meeting standards and guidelines. These guidelines are often abstractions–even W3 guidelines can feel like this)–that focus on meeting standards of acceptance levels. The problem is that in our rush to meet the standards, we miss providing a good user experience for our users with disabilities. Many sites and apps we test at Experience Dynamics have blockers, confusions or inappropriate content presentation that often meets the WCAG (Web Content Accessibility Guidelines) but falls flat on it’s face from a UX perspective.
Accessibility Compliance- what constitutes good enough?
Why is it that quality assurance (QA) efforts have a lower tolerance for bugs, but when it comes to accessibility defects 75% or higher websites and apps have major, minor or quality of experience issues? Probably because the focus of accessibility is on “good enough” versus quality of experience. Let’s examine this more closely…
Three levels of accessibility quality
WCAG offers 3 levels of compliance with most companies eg Apple, Google and Microsoft aiming at “AA” compliance. The levels of Accessibility compliance fall into two categories, major and minor issues, but neglect a third:
1) Major bugs: Show-stopper issues, that Assistive Technology cannot process rendering the site or app inaccessible.
Example: A pop-up dialog is not readable to a Screen Reader and cannot be tabbed with a keyboard.
2) Minor bugs: Issues that make the site slightly painful and cause errors or confusions.
Example: Over-use of gray can throw up contrast flags, making it difficult for low vision users to perceive a UI or branding element.
3) Quality of experience issues: Issues that cause users to miss a metaphor or interaction, and render the experience sub-par or inaccessible.
Example: A design that uses visual layouts requiring users to know what to do by seeing or visually understanding the next step required to use it. Blind users would miss the visual cues rendering the Screen Reader read-out non-sensible or inaccurate. Here’s a classic example from Amazon subscriptions management interface:
Image comments: In this table, the dynamic functions lean too heavily on the visual metaphor (floating buttons/icons) require you to know they are there. Keyboard access (a AA compliance requirement) to these buttons and icons is not supported. This table contains all 3 quality defects detailed above.
How to avoid quality defects in your Accessibility Efforts
Teams that are pressured to meet accessibility compliance, often ship sites and apps full of quality defects. The best way to avoid this is to perform “Accessible QA“. This is different from normal QA efforts or unit testing. Accessible QA includes both Assistive Technology (AT) testing, Accessibility Checker Tool (ACT) testing and Accessibility Testing with Users with Disabilities. Major and Minor bugs can be teased out from AT and ACT tools but only Accessibility Testing can reveal quality of experience issues, such as the visual bias example above.
Both designers and developers need to involve users in the accessibility compliance process– to ensure that you’re making your access sensible and coherent. The danger of not doing this is offering a fatiguing, circular or UI that requires excessive “de-bugging” from the user. We have noticed that most cases of trying to figure out an improperly optimized accessibility experience end in frustration or failure. Building Accessible QA into your development process is essential. It will help avoid building accessible sites and apps that are deployed with a “good enough” approach, but that miss the mark and cause the very compliance issues you were trying to avoid.
Learn more in this Free Webinar, Accessibility Testing: How to Correctly Evaluate Section 508
Register for our new online Accessibility Bootcamp!
