I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?
‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).
For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.
The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.
As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.
What’s normative in WCAG#heading-1
The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.
What’s not normative in WCAG#heading-2
Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).
There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).
For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.
The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.
The norm is the core#heading-3
In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.
That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!
Conclusion#heading-4
In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.
Comments, likes & shares (6)
????Jedi???????? and divdev reposted this
I worked in web accessibility in different setups: as a freelance developer specialised in accessibility, as a WCAG auditor and as a full time team member of the W3C's Web Accessibility Initiative. As a developer I would receive audit reports, as an auditor I would write them and as a WAI team member I would work on promoting and documenting the standards these audits are based on. An observation: in the developer role, advocating for accessibility can be the hardest in various ways.
Perspectives
Writing audit reports, a company would request in-depth feedback with the intent to fix stuff (ideally; sometimes it's just because the law says they have to ????). At WAI, I engaged with accessibility standards and practices on more of a meta level. When developing tools or resources, I never had to explain why I wanted videos to be captioned or have a visible focus indicator on the stuff we published, because everyone else on the team had worked with WCAG for years, often decades, and many had lived experienced to draw from.
In the developer role, I had more responsibilities than ensuring accessibility, I also had to make sure our assets didn't break under an updated Content-Security-Policy, fix a deployment pipeline or figure out with which templating language my client could use their design system most widely. And then there was accessibility, my main interest and priority. I mean, why have a web app if it's inaccessible… I would often do that work under the radar, sometimes because other developers in the team weren't interested or skilled in that particular area, sometimes because I felt it would take more time to get extra time for a thing than to just do the thing.
Accessibility and support
Accessibility is hard to do bottom up, I found. In some cases, especially when working for government and non profits, accessibility would explicitly be in the requirements and or I would specifically be hired for that expertise. This was great and gave something to work with. In other situations, it was much more of a challenge. Time would go into making a business case (I learned about WAI's business case page late), trying to get budget for external audits or screenreader licenses (procuring JAWS is no fun) and figuring out how to go about recruiting users with disabilities for user tests. And that's still the meta stuff.
When it comes to writing code as an accessibility specialised developer, you can ensure you follow lots of users with disabilities and accessibility specialists to try and learn about implementation issues early. You can find lots of good resources. My favourite are blog posts by developers and accessibility specialists who have tested a solution with users and go at length to describe all the ifs and buts you need to understand the nuance and compromise. But let's be honest, if you want to rely on the official documentation (normative or not) that is also used by browsers and assistive technologies, it can be pretty difficult to find out exactly what to do.
Gaps in documentation
There are systematic problems in accessibility standards documentation:
From the standards org perspective this is all explainable. There is a lot of work on few plates, the consensus process and organisational structure have, besides benefits, an impact on how responsibilities can be and are distributed. It's understandable, but has an effect. It impacts how effectively developers (and designers, content editors etc) can build accessible products. Even if from the standards side of things, you can only do so much to try and have standards that are implemented interoperably by browsers and assistive technology makers. There are relatively few people in the space who specialise in this.
Channeling one's inner developer
From the auditor's perspective, as well as from the standards org perspective, accessibility looks different. The system is, sadly, ableist and almost every website you look at has accessibility conformance and usability issues… it has often frustrated me and made me more cynical than I want to be. You write down the same issues over and over, knowing they are just a few lines of code. I always had to channel my inner developer again, and remember what it can be like. Yes, removing the line
outline: noneis trivial, and it's extremely ableist to keep it in, but what can a developer do if the QA and/or design departments flag it as a bug and they're the only one on the team who ‘gets’ this need. Let's not blame the developer, let's blame the ableist system we all operate in. Or, as Adrian Roselli recently said, ‘arm developers’ with useful feedback so that they are more enpowered to make the changes (being an auditor often puts one in this somewhat rewarding position).I don't know where I'm going with this, but thinking about what I'd like to see for the web if I had a magic wand, I would want to see better accessibility documentation (clear, up to date and user tested), more engineering budget for compatibility between standards, browsers and assistive technologies and have legal requirements that make it so that serious organisations see accessibility like they see security and data protection. At least some if not all of these wishes are in progress, of course, in various places… they have been for years, I just wish ✨ change ✨ could be sooner.
Developer experience and user experience
Some say ‘user experience is more important than developer experience’, and I'm all for that sentiment. Of course. Web accessibility is all about users with disabilities. That's the point of it. Developers ‘just’ need to do the job.
But companies who make products they want developers to use effectively, like browsers, have dedicated developer experience teams to try and ensure that developers can use their stuff well. To try and set them up for success. In their case, that makes good business. Might we, as the accessibility field, also benefit from better developer experience (of web accessibility) to get to more widely spread user experience?
What if standards orgs hired content designers, like governments with similarly complex content do so successfully? Isn't explaining standards essential when making standards? In the majority of cases, an inaccessible pattern can be addressed in code, by developers. Might some focus on developer experience be a sensible means to an end? If it was less frustrating to find out how to build, say, a combobox, in practice not in theory, we would more easily get to the end goal: less frustrating experiences to end users.
Besides a focus on quality of documentation, I feel like we should keep the individual developer's perspective in mind, acknowledging they may have constraints beyond their control. We could contribute to fight those constraints by providing executives and team leads with the right tools too. We've got to set teams up for success. That way we all win.
One way to make a UI on the web keyboard accessible is to ensure parity between input methods: that things that can be clicked, can also be activated with just a keyboard. In addition, you can also introduce keyboard shortcuts for common actions. If you do, ensure they require a modifier key, like
⌃ Ctrlor⌘ Cmd.Understanding 2.1.4
In WCAG, the standard used to check if websites are accessible, there is a specific Success Criterion for keyboard shortcuts, which got added in version 2.1. From the criterion text:
In other words: do not use keyboard shortcuts that are just a one letter character (or multiple of those). After the quoted part, exceptions are listed where such a keyboard shortcut would be ok, we'll get to those later.
Let's first try and get a little more explicit. Basically, you could do shortcuts that are a single key, like, ‘press
Nto open a new document’. Or your shortcuts could be in the form of⌘ Cmd + somethingor⌃ Ctrl + something, requiring a modifier key. This Success Criterion basically says ‘don't do the single key thing, always have a modifier‘ (again, with exceptions, see below).This criterion removes frustration for speech input users, who control their screen with their voice. Their software listens for words or sentences, but also for shortcuts. The issue is that shortcuts that don't use modifier keys could get activated up when the user didn't mean to.
An example from the Understanding document:
(From: Understanding 2.1.4, Intent; adapted to be shorter)
The criterion also improves the experience for people who are prone to accidentally hit keys, like users with fine motor skill related impairments.
So basically, the issue with these “unmodified” shortcuts, is that it is harder for software to establish if the user actually wanted to trigger the shortcut. The use of modifier keys is an established pattern that captures this user intent, you would not press those and another key accidentally.
What about
/?When I was testing a website recently, I found that
/was used as a keyboard shortcut. I wasn't a 100% sure if this was a WCAG failure per se. The Success Criterion text says keyboard shortcuts should not consist of just letter, punctuation, number of symbol characters. Is/any of those four things? Letters and numbers I know, but what exactly does the full set of punctuation and symbol characters look like? Why doesn't WCAG include a list?Well, there are two answers to that:
That last answer is what Marjon from the accessibility consultancy Firm Ground replied when I asked about my confusion on Twitter. She linked to the WCAG Technique document (yup, not normative), where “all number, letter, sign and punctuation keys” are summarised as “printing characters”. That checks out. I'll take this interpretation:
/is a printing character and should not be used as a shortcut on its own.Exceptions
I promised to get back to the exceptions that are in the Success Criterion text. It says you can use single characters without modifier keys as shortcuts:
/by default, but users can go to the settings of your app and remap it to be⌃ Ctrl + /selectmenu and press theTto jump straight to Taiwan (that way, it doesn't interfere)The remapping option can get tricky if your interface has a lot of shortcuts. The popular email web app that allegedly was used as inspiration for this Success Criterion has a very large number of unmodified shortcuts, so many that it runs into the case where there aren't enough characters to remap them all.
Summing up
Keyboard shortcuts are most accessible when they include modifier keys like
Thanks to Marjon Bakker and Eric Eggert for help with WCAG interpretation and Kilian Valkhof for the modifier key Wikipedia link.⌃ Ctrlor⌘ Cmd, so that they don't frustrate voice input users and users with fine motor impairments. If your interface has shortcuts that are just one or more “printing characters”, any character that prints something on the screen, best combine them with modifiers.