Website Accessibility, v3

Reading the W3C Specification

Jon Kuperman
Bloomberg
Website Accessibility, v3

Lesson Description

The "Reading the W3C Specification" Lesson is part of the full, Website Accessibility, v3 course featured in this preview video. Here's what you'd learn in this lesson:

Jon explains how to read the W3C specification, which can be helpful when developers want to understand the "source of truth" for how accessibility or other features are implemented in the browser. Reading the specification can also reveal areas for improvement and motivate developers to contribute to future versions.

Preview
Close

Transcript from the "Reading the W3C Specification" Lesson

[00:00:00]
>> Jon Kuperman: All right, so maybe a little mini lesson on how to read standard specifications, which I think is a very difficult thing, but a really important skill. So, this look will be familiar to you if you read any W3C specifications so, for example, this is the WCAG accessibility one.

[00:00:18]
But you could just as easily imagine like the W3C HTML spec, and you could click on the HTML5 spec, and it looks surprisingly similar. And you can do the same thing with TC39 specification, and find the 2025 and it looks more orange, but basically the exact same. So, these are the sort of outputs that we as standards bodies create, and we usually create them quarterly or annually, new features as they come.

[00:00:45]
So you can imagine with accessibility like these ARIA roles or attributes, it might actually be good just to kind of visualize how this works. So let's say that you come up with an idea for a new ARIA role that's like sorely missing, right? And what you do is you join W3C, either as a paying member or as an invited expert, and you attend the WCAG working group, the way group, working on this and you present.

[00:01:07]
I have this idea for this role that I think is missing. And it has to go through this consensus process and if there's consensus that it's important, it starts this kind of multi stage process where you as the champion is often how we refer to an ecma, have to come up with a problem statement, a solution, then you have to write a lot of this specification text.

[00:01:27]
And the point of this specification text, is that it should be thorough enough that every implementer, in like this case every browser should be able to implement the exact same bit of functionality. So it sort of becomes this thought exercise and like edge cases and rules and you really want to come up with this thing that for all HTML, CSS, JavaScript and accessibility, you should be able to take this document, give it to Google, give it to Apple, give it to Mozilla.

[00:01:54]
And they should come back with websites that render websites, with browsers that render websites in the exact same way. So the challenge becomes one of being extremely thorough. That sort of makes sense at a high level that you basically wanna think of. Here's the new rule, here's what it's for, here's how it acts, here's how you would implement it, here's how it works with other things, here's how a collision.

[00:02:14]
We had all these good questions today like, what about two assertive ARIA live regions colliding with each other, that should be documented somewhere. Or we had one on chat, which was like, what if your button's focus state is the same color as the button, but it is in contrast with the background, is that good enough?

[00:02:31]
So all these great questions, these are things that ought to be in the spec so that all the browsers can implement it in the exact same way. And when it's not good enough in the spec, we end up with divergent behavior, which can end up with a bunch of bugs and they're hard to fix later.

[00:02:42]
So, when you're looking at the specification, I think the important thing to know is that it's not authored to you as an application developer, it really is authored to implementers. However that doesn't mean it can't be a tremendous resource to you. So I'll give an example here with the example I just gave of the button and the focus.

[00:03:00]
We had a question in chat and I wasn't sure if the rules stated that the focus ring needed to be in contrast to both the background and the button, or just one I wasn't sure. And so what I did was I ended up searching through the WCAG specs, so 2.2 is the latest version.

[00:03:16]
It was released in December 2024, and I ended up finding this section on focus. And so I found the section on focus, and it gets overwhelming but truly it has a lot of the stuff that we would expect to see. So, it says what it's talking about, then for each section it'll say, is this AA or AAA, so you can see that we've got a AA rule and a AAA rule.

[00:03:37]
It's got some notes, these are like editorial comments that are like helpful things for implementers as they're going. And so what I ended up finding here was, I was kinda reading through, and it says, it's more vague than I'd like it to be that's what I found. So to be AAA compliant, the focus indicator when visible, needs to meet all of the following.

[00:03:57]
One, it has to be at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or subcomponent. That's pretty straightforward, right? It doesn't have to be 2 pixels, but it has to be at least as big as 2 pixels would be, right?

[00:04:11]
So it could be larger than 2 pixels, it could be like an as long as it never gets smaller than 2 pixels, this is a pretty reasonable idea. And then two, it has a contrast ratio of at least 3 to 1 between the same pixels in the focused and unfocused states.

[00:04:26]
This is more vague than I'd like it to be, right. So contrast ratio of 3 to 1 is like very clear between the same pixels in the focused and unfocused states. So there has to be some contrast between when it's not focused and when it is focused. But does the contrast have to apply into the button as well as out to the background or just one way.

[00:04:45]
My loose reading of it would be that you technically only needed to have, you could have a black button that has a black 2 pixel ring on it. I think that's a bad idea, I don't think we should do that. So if I had the time or energy, I would submit a proposal to this spec saying that, to be [APPLAUSE] compliant, the 3 to 1 ratio needs to be both between the background and the inner focused state itself.

[00:05:10]
But, the kind of idea here being put yourself in the mindset of an implementer of a browser, not an application developer, and kind of understand that, every single thing ought to be written in depth in the specification itself. So you really should be able to dive in here, and see if I'm building a browser, what do I add as a focus state, what does that need to be?

[00:05:31]
And you'll notice different browsers will have different focus rings or different date pickers, or different color pickers, things like that, but all of them adhere to this specification. So those deviances are maybe areas that we could have improved the spec, but they all meet the exact same when you hit escape, what does it do all when you hit tab, what does it do?

[00:05:49]
If you have two at the same time, how do they behave? Those kind of things. Any specific questions? I love talking about spec stuff, but hopefully that at least gives you like, this is what they look like, this is how to navigate them, and this is the tone that they're in and the reason why they're in that tone.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Start a 7-Day Free Trial