惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

U
Unit 42
P
Proofpoint News Feed
The Last Watchdog
The Last Watchdog
S
Secure Thoughts
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
N
News | PayPal Newsroom
Application and Cybersecurity Blog
Application and Cybersecurity Blog
O
OpenAI News
S
Security @ Cisco Blogs
宝玉的分享
宝玉的分享
Hacker News: Ask HN
Hacker News: Ask HN
T
Troy Hunt's Blog
Google Online Security Blog
Google Online Security Blog
WordPress大学
WordPress大学
有赞技术团队
有赞技术团队
TaoSecurity Blog
TaoSecurity Blog
Help Net Security
Help Net Security
Latest news
Latest news
NISL@THU
NISL@THU
S
Security Affairs
博客园_首页
C
CXSECURITY Database RSS Feed - CXSecurity.com
博客园 - 聂微东
AI
AI
www.infosecurity-magazine.com
www.infosecurity-magazine.com
Recent Announcements
Recent Announcements
P
Privacy & Cybersecurity Law Blog
小众软件
小众软件
cs.CV updates on arXiv.org
cs.CV updates on arXiv.org
Hugging Face - Blog
Hugging Face - Blog
博客园 - 司徒正美
AWS News Blog
AWS News Blog
W
WeLiveSecurity
Google DeepMind News
Google DeepMind News
I
InfoQ
Schneier on Security
Schneier on Security
Recent Commits to openclaw:main
Recent Commits to openclaw:main
T
The Exploit Database - CXSecurity.com
IT之家
IT之家
T
Threatpost
Scott Helme
Scott Helme
L
LINUX DO - 热门话题
腾讯CDC
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
N
News and Events Feed by Topic
L
LINUX DO - 最新话题
F
Full Disclosure
大猫的无限游戏
大猫的无限游戏
H
Heimdal Security Blog
S
SegmentFault 最新的问题

TetraLogical Blog

Designing for people with reading disabilities - TetraLogical Designing for people who are D/deaf - TetraLogical Designing accessible documents - TetraLogical Introduction to creating accessible documents - TetraLogical Inclusive user research: vulnerable people - TetraLogical Designing for people who are blind - TetraLogical Designing for people with low vision - TetraLogical Meet the team: Niamh Madden - TetraLogical Designing for people with anxiety - TetraLogical Designing for people with disabilities - TetraLogical Accessible building blocks for the web videos - TetraLogical Common accessibility misconceptions - TetraLogical Common misconceptions about testing accessibility - TetraLogical Common misconceptions about implementing accessibility - TetraLogical Common misconceptions about WCAG - TetraLogical Common misconceptions about disability - TetraLogical Meet the team: Grace Snow - TetraLogical Sustainable accessibility in complex organisations: strategic foundations - TetraLogical Sustainable accessibility in complex organisations: organisational realities - TetraLogical Sustainable accessibility in complex organisations: external factors - TetraLogical Common misconceptions about screen readers - TetraLogical Guide to the Inclusive Design Principles - TetraLogical Meet the team: Ian Lloyd - TetraLogical Annotating designs using common language - TetraLogical Meet the team: Catriona Morrison - TetraLogical Championing inclusive language - TetraLogical Press release: TetraLogical launches accessible self-led training courses to help digital teams build confidence in accessibility - TetraLogical Why inclusive products are green products - TetraLogical Accessible Recruitment - TetraLogical Accessibility and the agentic web - TetraLogical Meet the team: Craig Abbott - TetraLogical Foundations: types of assistive technology and adaptive strategies - TetraLogical European Accessibility Act (EAA) FAQ - TetraLogical Screen reader HTML support tables - TetraLogical Interview with Lola Odelola - TetraLogical Understanding EN 17161 Design for All - TetraLogical Inclusive user research: building rapport - TetraLogical Foundations: Keyboard accessibility - TetraLogical Can generative AI write contextual text descriptions? - TetraLogical Understanding the European Accessibility Act (EAA) - TetraLogical Meet Josh: a sportsman who has spinal muscular atrophy - TetraLogical Meet Jonathan: a photographer who has ADHD - TetraLogical Foundations: grouping forms with `<fieldset>` and `<legend>` - TetraLogical XR Accessibility: for people with moving disabilities - TetraLogical Meet Andre: a music producer and blind screen reader user - TetraLogical Foundations: types of disability - TetraLogical Meet Lauren: a film editor who has ADHD - TetraLogical Meet Steve: a photographer who is deaf and low vision - TetraLogical Foundations: form validation and error messages - TetraLogical Meet Hasmukh: a blind cricketer and screen reader user - TetraLogical XR Accessibility: for people with hearing disabilities - TetraLogical XR Accessibility: for people with thinking disabilities - TetraLogical XR Accessibility: for people with seeing disabilities - TetraLogical Introduction to XR Accessibility - TetraLogical Foundations: labelling text fields with input and label - TetraLogical Design patterns and WCAG - TetraLogical Does WCAG 2.2 apply to native apps - TetraLogical Why are my live regions not working? - TetraLogical Building a culture of accessibility - TetraLogical When to use tabindex= Accessibility foundations - TetraLogical Meet the team: Demelza Feltham - TetraLogical Can generative AI help write accessible code? - TetraLogical Meet the team: Steve Faulkner - TetraLogical Meet the team: Gez Lemon - TetraLogical Keyboard accessibility myths and WCAG - TetraLogical Amendment to the Public Sector Accessibility Regulations - TetraLogical What Considerations for TV user interface accessibility - TetraLogical Meet the team: Alistair Duggin - TetraLogical Sticky content: focus in view - TetraLogical The only accessibility specialist in the room - TetraLogical Meet the team: Ian Pouncey - TetraLogical Meet the team: Dean Holden - TetraLogical Meeting WCAG Level AAA - TetraLogical Foundations: accessible names and descriptions - TetraLogical Inclusive XR: accessible augmented reality experiences - TetraLogical Foundations: pointer gestures - TetraLogical Meet the team: Graeme Coleman - TetraLogical Adding sign language to videos - TetraLogical Foundations: introduction to WAI-ARIA - TetraLogical Meet the team: Joe Lamyman - TetraLogical Inclusive XR: accessible 3D experiences - TetraLogical Foundations: visible focus styles - TetraLogical Foundations: target sizes - TetraLogical Meet the team: Henny Swan - TetraLogical Meet the team: Ela Gorla - TetraLogical Foundations: native versus custom components - TetraLogical Foundations: HTML semantics - TetraLogical Accessibility and supporting Internet Explorer - TetraLogical Meet the team: Felicity Miners-Jones - TetraLogical Accessibility and QR codes - TetraLogical Inclusive user research: recruiting participants - TetraLogical Research insight: accessibility of images - TetraLogical Meet the team: Léonie Watson - TetraLogical Android accessibility: roles and TalkBack - TetraLogical Accessible design systems - TetraLogical Meet the team: Patrick H. Lauke - TetraLogical Inclusive user research: analysing findings - TetraLogical How to write user stories for accessibility - TetraLogical
Triaging WCAG 2.1 Level AAA - TetraLogical
2022-05-20 · via TetraLogical Blog

Posted on by Ian Pouncey in Standards, Testing

Tags: WCAG

If you've taken the time to understand WCAG 2.1 Level AAA and have spent time testing WCAG 2.1 Level AAA, what do you do with the results?

In testing WCAG 2.1 Level AAA, we looked at the twenty-eight success criteria for WCAG 2.1 Level AAA and suggested ways to go about testing against them. If you follow this process you will, almost certainly, have found cases where your site or application is not meeting the requirements of WCAG 2.1 Level AAA. But, as WCAG itself notes:

It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.

So, how do you decide what to fix and what to ignore?

Three groups of issues

When performing any sort of assessment there are generally three groups issues fall into:

  • Fix
  • Won't fix
  • Not relevant

Most of the time issues will be in the Fix or Won't fix group; so why would something that is Not relevant be included as a test in the first place? Because you've tested against a defined set of criteria, you may find issues that just aren't relevant just as you would at Level A and Level AAA.

Let's look at the different groups and what issues you should include in each.

Fix

These issues are, naturally, the ones you intend to fix. You can identify these in two ways:

  • Does this issue present an accessibility barrier to your audience?
  • Does fixing the issue significantly improve the user experience, particularly for people with disabilities?

The first point is something that differentiates WCAG 2.1 Level AAA from Level A and Level AA. While Level A and Level AA are both intended to be used for general accessibility, WCAG 2.1 Level AAA is intended to be used for specific content, audiences, or circumstances.

For example, do Deaf users make up a large proportion of your audience? If they do, then a lack of sign language may be a significant barrier, so meeting SC 1.2.6 Sign Language (Prerecorded), may be more important for your site or application than others.

The second point captures more general benefits to meeting WCAG 2.1 Level AAA. An application for a summer music festival may benefit from greater contrast for text as it will (hopefully!) be used in bright sunlight. SC 1.4.6 Contrast (Enhanced) could be a success criterion you want to meet.

Won't fix

You may decide there are things you won't fix. It may seem odd to test against a standard and then choose not to fix issues, but for WCAG 2.1 Level AAA, this is expected for reasons described in understanding WCAG 2.1 Level AAA.

For example, SC 3.1.5 Reading Level is as follows:

When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

However, for a scientific journal with an audience that is predominantly people with an advanced education level and used to reading scientific articles, this may not be necessary. Simplifying the language may, in the worst case, make the content less accessible to its intended audience if less precise terms are used to meet a lower reading level.

This doesn't mean that you should always ignore issues raised. You may want to use the failed criteria as the basis for setting your own requirements, perhaps using a higher reading level as your target.

If there are issues that you don't want to fix now, include these in the Fix group; fixing later is still fixing, and so should not be included in the Won't fix group.

The important thing that Level AAA testing gives you is the ability be able to make an informed decision. You should document whatever decision you make, along with your reasoning, so that the decision can be reassessed in the future or applied consistently in other circumstances.

Not relevant

This is everything else, the issues that are not applicable to your content. You haven't failed them, they just haven't been tested against. If you don't have multimedia content then all of the criteria under Guideline 1.2 Time-based Media do not apply.

You shouldn't forget about them, though. Content and features of sites and applications constantly change. Keep this group of success criteria in mind as features are developed and content is added, and test against them if they become relevant.

What to fix first

When testing against WCAG, the level gives you the first piece of information that you need to determine the order to fix issues. In most cases, you should fix Level A issues first, followed by Level AA. Sometimes, when a Level A criterion is a stricter version of a Level AA criterion, you can fix both at the same time, so it's worth looking ahead to Level AAA issues at the same time. The same applies to evaluating Level AAA issues; check if there is an enhanced equivalent at Level AAA that you could meet.

For example, if you need to increase the contrast of a piece of text, are you going to increase it to 4.5:1 to meet the Level AA requirement and then think about increasing it to 7:1 to meet the Level AAA criterion later, or does it make more sense to jump straight to the enhanced contrast level? Almost certainly the latter.

The second thing to consider is the severity of the issue. This is less likely to include Level AAA criteria, as they are, by their nature, generally less critical than Level A or Level AA criteria. The same principle of looking ahead applies here as well. Remember, WCAG success criteria define the minimum expectations; Level AAA often raises the minimum expectation but often does so in ways that will benefit your entire audience.

The third thing to consider is your audience. As Level AAA criteria may more beneficial to specific user groups than the general population, you should always look to it if you have a particular target audience. If your target audience is predominantly a group of people with disabilities that would benefit from one or more Level AAA success criteria, then you may even wish to prioritise these over Level A or Level AA criteria.

Conclusion

Testing against WCAG 2.1 Level AAA is a great way to get a better understanding of how your site or application might be improved beyond the Level A and Level AA success criteria. By including specific criteria in your regular testing, you can ensure that you are not just meeting but exceeding the legal requirements for accessibility in most countries and, more importantly, making your site or application more accessible and more usable for people with disabilities.

Find out more about assessments at TetraLogical or read our WCAG primer to learn more about the Web Content Accessibility Guidelines.

Next steps

Find out how we went about meeting WCAG Level AAA on the TetraLogical website, or how assessments can help you identify issues in your websites, mobile applications, design systems, and other products and services.

Updated 21 April 2023.