Eric Meyer: Hello and welcome to Igalia Chats. I'm Eric Meyer and I'm a developer advocate at Igalia.
Brian Kardell: And I'm Brian Kardell, also a developer advocate at Igalia. And today we have two guests. So Alice, do you want to introduce yourself?
Alice Boxhall: Yeah. Hi, I'm Alice Boxhall. I'm a web standards engineer at Igalia.
Brian Kardell: And Val?
Valerie Young: And I'm Valerie Young. I'm also a web standards engineer at Igalia.
Brian Kardell: Both Val and Alice specialize to a degree in accessibility, I would say. Val is the co-chair of the ARIA working group. Alice recently wrote a blog post, a threat model for accessibility on the web. It was a thoughtful post and we occasionally ask people, hey, what aren't you hearing on Igalia Chats that you would like to hear about? And a bunch of people mention accessibility and several people mentioned Alice Boxhall's post. So yeah, we thought that we would come and chat about that. So do you think that you could maybe give us a brief synopsis of what your post was about?
Alice Boxhall: I can try. I did manage to write a very brief blog post. I sort of get to the point in writing the introduction that the primary debt for accessibility on the web is neglect, and I traced the neglect back to the systemic cause of ableism. I didn't actually use the word ableism in the post, but if you click all of the links, one of the links goes out to a talk given by a friend of mine, EJ at CascadiaJS in 2019 titled, 'Accessibility is a Hydra.' And they talk a lot about ableism in that talk and it's a really great talk and it sort of influenced a lot of my thinking on this.
Brian Kardell: We'll share a link in the show notes.
Alice Boxhall: Thank you. The way that I put it in the blog post is disabled people are much too often seen as expendable. That's web developers and web platform engineers equally, sort of without thinking about it, make decisions that throw disabled people under the bus. Give a bunch of examples of things that shift as web standards that have sort of fairly glaring accessibility pitfalls with them, that make the job of accessibility specialists working downstream of web standards in front end development, makes their job sort of increasingly difficult as if it's not difficult enough to begin with. And then I conclude by saying that just as in front end development, accessibility specialists are always talking about the need for shifting accessibility earlier in the process and starting with the requirements process. And I think that we need to do the same thing in the standards world. We need to actually start our requirements processes with looking at the needs of users and specifically the needs of disabled users. And that means developing an awareness of accessibility as a basic core competency for standard engineers.
Brian Kardell: There are a lot of things that go into that. I think to be clear, I don't believe that what you're saying is this is a conscious thing even, right?
Alice Boxhall: Not at all.
Brian Kardell: I think there are lots of ways that this goes off the rails and it happens on both ends, like you're saying. So web developers, if you don't work for a browser, but you make websites, design comes in, they have all these cool ideas about how you're going to interact with the page that don't map cleanly to any known interaction model. And frequently, even if the interaction model is known, we don't code it properly and it's left as a sort of exercise for people at the end. Well, we'll just hire somebody to do some quick remediation, and kind of undervalued. It's not valued.
Alice Boxhall: Right.
Brian Kardell: It's like you're either an engineer or an accessibility specialist, you're not sort of seen as the same. It's like one of those is seen as really valuable day to day and the other one is seen as somebody who mainly causes you pain or something, right?
Alice Boxhall: Right. Yeah. So what I said in the post is there seems to be an assumption in front end development but equally in standards, that accessibility is something that you can kind of fix up, as you were saying, at the end with a root mechanical effort. And that is a sort of circular logic with assuming that accessibility is a low skill profession.
Valerie Young: So to add a little bit of pulling aside the curtain about this problem of creating web standards that have accessibility holes in them. So web standards, sometimes they take existing interaction patterns that have occurred on the web and try to make them easy to use using the infrastructure of the web HTML and CSS, et cetera. But that interaction pattern for someone who's using an assistive technology needs to go through the browser and through accessibility APIs, which are platform specific. So there's an accessibility API on Mac, on Linux, and on Windows. And then it needs to interact with the assistive technology like a screen reader. So if the new UI component is created without thinking about that chain of communication between the browser through the accessibility API, which is kind of like a funnel to the assistive technology, if the accessibility API and the assistive technology don't have a concept of that new UI pattern, they don't have a concept of a switch for example, then you need to work on those technologies also to be able to have default accessibility support for this new UI component that's embedded in HTML and CSS. So this is the part that in particular is very important to do early on because there's no remediation effort you can do if those concepts don't exist in accessibility API and in assistive technology.
Brian Kardell: Yeah, definitely. I think one of the things that's really difficult here is that it's really hard to just navigate the space of standards, period. And I think with accessibility, it's a whole other level because you also have assistive technology itself. You only get something that is successful if the developers do all the things right and then the browsers did the things right, and then every step along the way. And sometimes there's things that it seems like you did right, but still for some screen reader pair or something, it just doesn't work. And that's also really challenging. And in my experience, it's things like that that put a little bit of a damper on developers. Developers get really frustrated with that. I hear a lot of frustration toward, but it's like I am trying, but it's really difficult. And I mean, I can kind of relate to that a little bit. I don't want to give that as an excuse or anything, but I can understand that because we have, for example, the ARIA practices guide, APG, that is made by accessibility professionals and some of those patterns, people still don't agree on them.
Valerie Young: Right. So say a little bit about the APG. The APG is for design patterns that don't have a native HTML CSS component. So it's when people create new interaction models on the web and then we try to create a way to add that metadata back so that the screen reader knows what the thing is. So it's not just divs and spans. So the APG is kind of like for things that are stopgap before we hopefully have HTML and CSS fully supported accessibility built-in components. But it is a problem. I mean, Alice talks about this in one of the examples on the web. Someone did something right at some point, they filed an APG pattern, but then a later engineer doesn't know the importance of the pattern, the importance and meaning of a particular ARIA attribute and tweaks it in some way.
Alice Boxhall: Yeah. So not specifically an APG pattern in this case, but it was adding a screen reader-only, some screen reader-only text using sort of a CSS style, which effectively it makes the text non-visible without removing its CSS box. If you look at a typical screen reader text style, they're often very sort of wordy because you kind of have to get it just so, so that the screen reader doesn't detect it as non-visible and not speak it. So it's kind of a very fine line to walk. So what I surmised was that someone had added the screen reader-only text, which actually they don't need anymore to begin with, but someone had added it back when it was necessary and then someone else had come along and be like, oh, why are they doing all of this thing just to make a thing not visible? We can just make it display none. There, I fixed it. Not realizing that by doing that, they completely defeated the purpose of having the text there at all.
Valerie Young: Right. So even if you do something right according to the APG or according to these essentially hacks that accessibility experts on the web know in order to get information to someone who's using a screen reader for example, you can do it right one time, but the thing is that what do they say? Bits rot very quickly on the internet.
Alice Boxhall: Yes.
Valerie Young: Things are always changing. Another developer might come on who isn't an accessibility expert, so this remediation effort is obviously going to shoot you in the foot when things are changing constantly. You can't be everywhere at once reviewing every piece of code that lands.
Alice Boxhall: And I think accessibility tends to regress particularly quickly because it is not noticeable to the majority of developers working on this, both because they don't experience the need for that particular type of accessibility, but also because they don't have the expertise to look for it.
Brian Kardell: So this is maybe a good place to talk about when we do make standards, there's this balance. I was just mentioning to Alice this morning, Alex Russell's recent post that talked about how standards are made and his kind of sense that well standards aren't really made in a standards organization. They're finely written down there and then the sharp bits are filed off, whatever. And proposals do frequently come fairly fleshed out, but frequently they come a little too far. I think the biggest problem that I see with standards is its kind of a very complicated queuing problem, where there are inputs from so many directions asking for your time and the expertise is not enough to be constantly monitoring that and giving feedback. And then sometimes even when feedback is given, it's not understood or the weight of it isn't understood. I guess in the end the trouble is that frequently the people doing the submission in the first place aren't really the experts for accessibility and they make some maybe problematic proposals in the first place, and then they wait for a long time to get some feedback. They're not hearing any feedback. They think that means we're doing a good job. And then when they do finally get some feedback, if it's not hit the brakes, please don't ship this. Literally in those words, it just does kind of keep moving forward. And I kind of don't know how to manage this. We've had a couple of conversations and it's not only with regard to accessibility, I mean, it also is a problem for privacy and internationalization and some other things. Like, how do you get the course correction at the earliest time?
Valerie Young: Right. So in the development of open standards, there's a few different times when accessibility review can happen. Some of it is mandated by the process of standardization according to, for example, the W3C. There's this concept of wide review that happens before a specification can become an official standard. And then there's also during the process of the standard becoming discussed in a working group, for example, in CSS working group or in WHATWG for HTML or in OpenUI where a lot of brainstorming about new web features is currently happening. And Alice in her blog talks a lot about the difficulty of having accessibility conversations in the early development, and the informal discussions that happen in these working groups. And I don't think that you talk that much about wide review in the W3C, but part of... Alice is shaking her head, I can see. Yeah, part of the problem with wide review is that it happened so late. There's been so much work to develop these standards. There's been implementation in browsers, there's been hype. Essentially people want the feature. So when wide review happens, it's pretty late in the game to require significant accessibility changes, and somehow it really doesn't catch some of the problems that Alice talks about in her blog. And maybe Alice, you want to talk a little bit about what it's like to try to give accessibility feedback earlier on in the discussion.
Alice Boxhall: So yeah, I wanted to pick up on a phrasing that you used there that puzzled me a little bit. You said it's pretty late in the game to require significant accessibility changes, and I think what you meant to say was it's pretty late in the game to require significant changes on account of accessibility.
Valerie Young: Right. That's great.
Alice Boxhall: So you could could imagine reviewing something that is just about to ship or has already shipped and being like, okay, but this is horrendous for accessibility. You have to completely go back to the drawing board and that's just not going to fly. So yeah, I guess giving accessibility feedback earlier on, the main example that I've experienced of that was the CSS inert, which kind of shipped in Chrome earlier this year, and I came in relatively late only because I heard about it by accident. It was not super late, but it was certainly after I feel like that direction was already settled on. And for context, Brian and I both worked a lot on the inert attribute in HTML, so sort of that was in HTML and then it was removed and then we were like, oh no, we actually think we do need this. And so we spent a lot of time advocating for it to be re-added, along with other people. So yeah, I had quite a lot of experience with thinking about inertness and how it's used and how it's implemented, and I looked at that and I was like, oh, I don't think this is a good idea. And so I left a comment in the GitHub thread where it was being discussed. And it was just kind of this process of trying to be heard and just constantly feeling like what I feel like is strong pushback is being interpreted as if it's just sort of a misunderstanding or asking for a tweak. So I sort of list out basically every single place where I pushed back and others pushed back in the blog posts just to single little links, I don't include the text of each one. But if someone went through and clicked all of those, you can see me just sort of becoming increasingly desperate as it goes on until the final one is just a long bulleted list of my concerns saying, 'Please don't do this.' But it still shipped because that was just way too late in the process by that point. So yeah, it just sort of feels like trying to be heard and not being heard regardless of what you say almost.
Eric Meyer: The parallels, I mean, they're frustrating, but they're very, very strong, that the experience that people who care about accessibility have in web design and development are the same that are happening in the standards process. It sounds like the same story. Or it's not exactly the same story, but it sure rhymes, where accessibility is only considered at the end of the standards process, and a lot times there's only standards feed... Or sorry, a lot of times there's only accessibility feedback because the person who cares about accessibility just accidentally happened to find out that a thing was shipping. And so it's kind of pervasive and one can understand why the community of people who care about accessibility throughout all of this, throughout the entire web space, are tired and frustrated a lot of the time.
Valerie Young: There's something a little unsaid in the story that Alice brought up, or maybe it is said, I can't remember how explicitly this is talked about, but it's hard socially when you're attached to a project to when... I mean, you know people say it's their baby, it's their prodigy. The thing that they're giving to this world is a change to the web that, I don't mean to say it in a harsh way, but your ego is tied up in that which is relatable. I think we've all had that experience before being really tied to something really in a way that isn't always totally clear to us as well. It's not like we're 100% aware of the fact that the reason why someone might not listen to Alice's feedback is because they're so attached to this on an emotional level. We're not always that in tune, but it's present. And I wonder what there is to be said about that. I think sometimes cultures of groups can help set up norms of being more open to seeing a proposal not go through to fruition. If you see examples of other people very gracefully realizing in a group that their idea probably should be rolled back, even pretty far along in the game. If you see that kind of example, I think that it's extremely moving and can really reoccur... The effect of having seen that happen can allow you to also more easily realize that something that you put a lot of work into actually needs to be shelved, for example. And to have enjoyed the process of trying to develop this idea rather than feeling like you need something to show for it. But that's a little bit difficult in our society and the way promotions happen, the way jobs are structured, that you need to show that you've achieved something, not show that you put a lot of effort into a process and realized something didn't work out. That's something we're up against.
Alice Boxhall: Having worked at Google, a big corporation where this happens, kind of like the big corporation where this happens, having experienced the frustration of trying to get something done, actually not even just in web standards, trying to do something and then working on it for 18 months or whatever, and then just at the very last minute, someone coming in, someone with actual power to stop it, coming in and saying, 'No, you can't do that.' And just like, it is, it's gutting. As you said, this is your baby and this is something that's important to you. Even leaving aside the pragmatic aspects of you might have been depending on this to get potentially a long overdue promotion in a lot of cases. Especially working on the web platform, it's already difficult to show the kinds of rapid impact that is expected at these corporations. But I also wanted to say that is another thing that I think makes it difficult to give that negative feedback because you don't want to go to someone and say, 'This is bad and you should feel bad,' because you don't want to make them feel bad. You want it to be a collaboration, because at the end of the day, you do want the same things, but when you are put in this position of, I have to push back on this, all of a sudden it's a zero-sum game and one of you is going to lose, and that's like someone has to lose and everyone loses. Yeah.
Brian Kardell: I mean, there's so much here. I do want to say that I don't think that there are many people who are even doing this callously. I know for example, on the carousels, I know that Rob threw himself into trying to understand the problems, but that's not his background. And so he thought that he understood those pretty well. He brought them up in a few different venues, but I mean, we can relate to this because we have... I think I've said this a few times, but we both worked on focus visible, which realistically we could have defined, implemented, and shipped everywhere in six months, but it took seven years. And a lot of the reason that it took seven years is because it's like you can imagine we're on a street in New York City just shouting ideas and hoping that the right person hears it. Do you know what I mean? And if they don't, then eventually, maybe six months down the road somebody's like, well, 'Hey, Brian's idea is getting some traction.' And you're like, 'Well, what idea? I don't know anything about this idea.' And then you learn something about it and now you're going to weigh in on it, and it's like just getting people's time and everything is difficult. And then when you do have that feedback, it's like you say, nobody wants to be like, this is bad and you should feel bad. I mean, I've been on some things trying to correct. I think Alice and I have been on some things trying to correct something that we thought, this is not a good idea, but let's try to make it as palatable as possible because somebody is really driving this and is this the hill that you want to die on? How critical is it that you stop this thing? But I mean, I think that this is true of everything. We put the W3C technical architecture group review in the way of the shipping process for Chrome. In the roughly decade, that has been a thing. There are over 1000 issues in there. That's a lot. I mean, every one of those is an idea that came with an explainer and research and discussions, and there's only a tiny handful of people ever on the TAG. Sometimes things end up in that queue for two years, three years, because there's just not enough way to manage those queues. It's really, really hard. And I don't have any great answers. I feel bad because I know that people try and I want them to succeed, and I don't want them to get frustrated, but I also don't want bad stuff to shift. So I don't know.
Valerie Young: Right. So on that very question of what do we do about this? And of course I think that we all feel, what do we do about the lack of accessibility on the web? Or my feeling and the feeling of a lot of other people in web standards is that the solution is to have accessibility built into the tool. And this is why we're focusing so much on the problems or the things that prevent accessibility from getting built into the tool from the very beginning, which is mostly a lack of accessibility expertise of the people designing the tools, and then also the attachment to the proposal, which happens in a very human and relatable way. And what is the answer? Obviously, as Brian pointed out, waiting for TAG review, which is an option that you could do for W3C standards. You can ask for review of a particular issue from the TAG, the technical architecture group, and then you can wait for accessibility-wide review, which happens right before publication, but unfortunately after implementation and a lot of discussion and even more attachment to the proposal. So another idea that gets proposed often is that we just need more accessibility experts in the room. I hear this in the ARIA working group. People often in the ARIA working group who are paying attention to these different channels ask for more people to attend different kinds of meetings. But again, there's this problem of time. People only have so much time. People only have so much time to work on web standards. Their jobs only allow them so much time. Their lives only allow them so much time. So how do we get accessibility into the very beginning of the proposal? That's really what you need. The very, very beginning, the first idea. The first time someone's like, I want to make an accessible carousel. They need to find an accessible expert and co-design it. At that point, I personally don't really see any other options. Maybe there are something we've overlooked, but that's ideally what I would like. Is when people are creating new features, that when they have the idea of a desire of a new feature, that's when they start to understand the constraints of accessibility. And that is something that can only happen if there's cultural and perhaps process changes within the groups that create these proposals. I wonder what you have to say, and my perspective, OpenUI is a really rich ground for trying to come up with new web paradigms or web features, there are some people from the ARIA working group who also attend those meetings, and my understanding is that accessibility discussions happen pretty early on there. Brian, you attend those groups, right? What do you think of-
Brian Kardell: Yeah, I mean OpenUI is early in definition by definition, because it's where you take things before it necessarily even is ready to be its own WICG thing. It's like there's enough interest here. We recognize this pattern, there's data to show that this is a common interaction pattern and we agree to tackle it as a group. So yeah, I mean, the discussions in there go early, but early is also something that we should define because what became select menu and popover and interest target, those things I think have been somehow in development and conversations for six years. So that is still early in some respect, but at some point it gets really demoralizing when somebody wants to kind of start over or you have this sunk cost fallacy. This happened actually with the select menu. We did all this work with select menu, we had all of these discussions, all of these accessibility discussions about how that should work and what we thought should be the guardrails of that. And then we finally got it to what WHATWG, and they were like, 'No, no, no, none of this is going to work.' You kind of go back to square one.
Valerie Young: Was that pushback from accessibility?
Brian Kardell: No, it was actually HTML editors, but it's hard to let go of that. I will say that the thing with OpenUI is that it's more open than say CSS working group or ARIA working group in that you don't really have to belong to anything to attend those meetings. But there are weekly meetings, and at a minimum it's a one hour, but if you want to prep for the meeting, you want to participate in all that, you can figure four hours a week or something like that is a reasonable amount of time to sink into that. And it's largely voluntary or the people who come are again being paid by browser vendors. And so we have two or three accessibility people in that that are doing a herculean amount of-
Valerie Young: Right. Even in-
Brian Kardell: ... effort.
Valerie Young: ... OpenUI, there's more proposals than an accessibility expert volunteering their time could reasonably-
Eric Meyer: And as far as I can tell, the entire accessibility space is pretty much volunteer.
Valerie Young: There are definitely, from the ARIA working group, there are some people who are able to work on web standards and accessibility during their day job. It's like a permitted use of their time.
Alice Boxhall: Included.
Valerie Young: For example, myself at Igalia, thank you Igalia for funding my accessibility work. But I think a lot of people that even those work hours blur into volunteer hours.
Alice Boxhall: I think as you said, it is often a sort of a combination and for a lot of people, I guess this is true of a lot of things, but yeah, it is something that people do because they care about it by and large. And like I said, that's true of a lot of web standards. Just a lot of the job is people getting involved because they see a need. And then once you see that need, it's really hard to stop. But yeah, with accessibility, it's so easy for it to be invisible to people and it's so understaffed because of the systemic reasons that I try to get to in post. That it's not visible to everybody and disabled people are often ignored. It's not valued particularly in sort of a financial sense, and this is why we need regulations for it, but then the regulations are not necessarily strong enough to be the forcing funding that maybe we need. So yeah, the whole thing ends up just being drastically understaffed and the people who work on it are doing kind of five jobs just to try and keep up.
Eric Meyer: And Brian has observed before that, and we talked about here, that part of the systemic imbalance is that generally the people making things are getting paid to make them and the people who are trying to make things accessible or volunteering to do that, and that is in itself an imbalance. You have very different incentive structures and of course, if people aren't being paid to make things accessible, that's going to limit the pool of people who are willing to volunteer their time. And so that shrinks the population. I wish I could see a way out of this. I think in the standards process, there's a way out of this. Certainly in the standards process, the process could be changed to require accessibility evaluation in the very first stages, for example. Well, this is true.
Brian Kardell: Who's paying for it? That's the thing, because you can require it, but if it's volunteers, then-
Eric Meyer: Again, the standards process could, not saying it would be easy, but it could be modified to place the emphasis upfront.
Valerie Young: Right. On the question of whose paying for it? I mean, who's paying for these standards to appear at all? And a lot of standards currently are spearheaded by Google, and Google spends a lot of money on standards. You think that they could also hire some accessibility specialists in their company-
Eric Meyer: Yeah, you'd think that.
Valerie Young: ... to work on those standards as well. And sometimes that is what they do. I mean, Google's a huge complex organization and sometimes the right people are in charge of the purse, and that's great and does happen many times and I'm very thankful for those people. I mean, it's up to individuals in the hierarchy to make those decisions and they can make them again.
Brian Kardell: I think it's kind of not enough at any of the orgs, especially at the ones that spend a lot of money turning out ideas and proposals. So currently that's Google, but maybe in the past it was Microsoft, for example.
Valerie Young: Yeah, even right now, Microsoft is actually paying for some pretty cool accessibility features to be developed in a really thoughtful way. Like ARIA Notify coming soon.
Eric Meyer: Say more?
Valerie Young: Okay. Sorry. Let me orient around that. ARIA Notify is supposed to be a better solution to what was one of these kind of stopgap or a feature in the web that was never very well-made from a developer perspective using it and from a screen reader user also experiencing the effects of that, which is live regions. It's the way that when a visual user looks at a screen, you sometimes know that something happened because of a visual change. For example, you know that you got to reply to a message because you can see the message appear on the screen, but you might be looking at something else, but in your vision you can tell something happened down there and your eyes are directed to it and then you can look at it and read the message you got from your friend. So if a screen reader user is using the web and they're reading some content in a different part of the page and then they get a notification from an in-page pop-up, like a support person notification, they need to hear that something changed in that part of the page. They can't just see that something changed in that part of the page. And that's what live regions are for. Having a notification when something changes in a page or a part of a page. But it's clunky, it's difficult to do right. So Microsoft is funding ARIA Notify, which is supposed to be a better, more easy to use, easy to integrate with screen readers version of live regions.
Eric Meyer: I like it. Sounds pretty cool.
Valerie Young: Yeah. What were you talking about before that?
Alice Boxhall: Yeah, I think I did have actually something to say about what we were talking about before that, which was Eric was saying that perhaps the standards process should require accessibility to be addressed earlier. And I'm not sure exactly how that would play out because I think Brian, you mentioned Alex Russell's series on web standards earlier, and I think that the first person in that series makes a pretty compelling argument that standards are what happens at the end of the process, by definition. So I think it would be tricky to say for standards to have any sort of impact on something that should happen at the start of the process. Yeah, I don't think standards can unfortunately be a forcing function there potentially, but rather I would, yeah, I think some combination of what Valerie was suggesting earlier about actually thinking about ways that we could set up the possibility of taking no for an answer, but also just a holding one another accountable for having that, for considering accessibility in the process such that you don't need to get to that point of having to say no.
Brian Kardell: I think there are some trends like explainers that can help, because one thing that's very difficult is even, I know Alice, you probably can relate to this because Alice and I have been part of some, I don't know what you want to call them, like mega threads that have two or 300 replies and then link to another issue with another 150 replies. And you just sit there. And if you ask a question about something that it hasn't been even discussed for six months, and then suddenly it gets hot again and it gets 20 replies in one day, and then you're like, 'Hey, Alice, what about this?' And you're like, 'Oh my God, I have to refresh my memory on this giant mega thread.' One of the things with explainers is that you can go kind of early and describe, in relatively short words, these are the use cases, these are the things we consider. These are the goals, the non-goals. I think that there's room for us to improve that part of it.
Valerie Young: Right. An explainer is something that often it's a term in the web standards development that refers to a document which in, not in spec language, but in regular language, describes a feature, gives examples, describes the problems that are not yet resolved around the feature's development and various things like that. And the requirement of explainers for new features is mixed. Obviously, every working group has a different way of working.
Brian Kardell: Also what even requires an explainer, right? So does the inert require an explainer? I don't think that it had one.
Alice Boxhall: It did.
Brian Kardell: Maybe it did.
Alice Boxhall: Yeah, totally did.
Brian Kardell: Did it? Okay. But it wouldn't be required for CSS working group.
Alice Boxhall: Oh, sorry, you mean that in a, yeah, CSS inert. No, absolutely not.
Brian Kardell: Yeah. I know that there was a repo that had a lot of stuff in it, it might have had some explainer on it.
Alice Boxhall: Yeah. So for CSS carousels, there was sort of a meta explainer for everything, but there was not an individual explainer for CSS inert. It was just sort of considered part of that. So even though there was nothing to keep it to that use case, there was no explainer for what problem it was solving outside of that use case. So it was just kind of like, well, if you know, you know. Meaning there was also no discussion of potential alternatives for any of those use cases or any of those needs because those needs were never written down. They were never discussed. It was just kind of, as you said, it was in the mega thread. There was sort of some people saying, 'Oh, it might be useful for this and it might be useful for that and maybe it should work this way and maybe it should work that way.' But those were never captured in any document.
Eric Meyer: Yeah, this is why I'm on team explainer, all the things. I think everything should have an explainer basically before it really gets underway. Just because that way you have a thing where somebody says, 'This is the thing I'm trying to solve, this is how I'm trying to solve it.' And other people can look at it and say, either that's probably not a good idea or that sounds awesome. And also, it might apply to these other things, and then the person who originally did it can maybe say whatever, just explainer all the things.
Brian Kardell: Yeah, I think those things should even be linked up in specs and stuff-
Eric Meyer: Yeah, well part of it.
Brian Kardell: ... because even once you get to that, it's super useful to be able to say, 'Gee, why is it this way?'
Valerie Young: The explainer should end up on MVN. I always feel like MVN could have more information on it.
Eric Meyer: And I mean, part of the time MVN is the explainer, even since there's not a lot to it. That's the only real explainer you can find.
Alice Boxhall: The most important thing that an explainer should do is explain the problem. I've certainly experienced this, that when you start working on a problem, you don't necessarily understand what the problem is. You're not necessarily at a point where you can just write down the problem. You have an idea for a solution to a problem that you just kind of feel in your gut. But I think it's worth taking the time to even iterate between those two things to sort of figure out, okay, I know I want this thing, but why do I want it? What problem is this thing that I want solving? Because often you can end up, once you sort of nail down the problem being like, oh, actually there is a much better solution. Now that I can see the problem clearly, I can refract it a different way, and there's a really simple solution. So this is something that I also come to in my posts that we wrote in the TAG design principles. We did a bit of a reworking of the priority of constituencies. It was in the HTML design principles originally. We took the original wording and changed it to emphasize the user need. The second sentence in the reworked version is, 'When beginning to design an API, be sure to understand and document the user need that the API aims to address.' And I sort of unpacked that sentence in the post, but I wanted to talk a bit about an example of where I've experienced this myself, which is with the AOM project way back in the day. Which we had this idea of a thing that we wanted and the thing that we wanted was a thing like the DOM API, but for the accessibility tree. We're like, 'Yeah, this would be really neat if we could do that. Instead of using ARIA attributes, you could write to the accessibility properties directly of an element. Wouldn't that be fantastic?' And we actually did get told no. 'For performance reasons, this is actually not a good idea for a bunch of reasons. This is actually not a thing that you want to do.' So we were like, 'Huh, well, but we should be able to do this, and why do you hate accessibility?' And it was like, no, actually, eventually we were convinced, no, this is not a thing that we want to do. So that really forced us to think about what we were trying to do with it. And we ended up breaking it down into I think four or five... We came up with four phases, but some of those phases had different problems. And so part of it was shadowed arm, so that's sort of like can trace... If people are familiar with reference target, you can trace reference target all the way back originally to that AOM idea, and sort of trying to figure out how we can create references across shadowed arm. Similarly, the element reflection, element reference reflection, looking at custom elements and default accessibility for that without having to set ARIA attribute goes back to AOM as well. So there's now work going on to expose the accessibility tree in WebDriver for testing purposes. So that also goes back to that original first project. But yeah, it wasn't obvious to us immediately that those were the problems that we were trying to solve. It wasn't until we were told no, that we were forced to kind of go, okay, what are the problems and are there better solutions? And I think all of those solutions are better than the thing we originally came up with.
Valerie Young: Good success story.
Brian Kardell: One of the things that I think ultimately is really difficult about this is something I said at the very beginning. There are named patterns that are part of ARIA, things that have ARIA roles, for example. I think if you ask a lot of developers like, 'Hey, we need this tabs. We need tabs.' They're going to go to the ARIA practice guide and use that as a... Even though it kind of says it's not, they're going use that as, well, this is what the experts are saying. So I'm going to study that, I'm going to copy that.
Alice Boxhall: The way I think about APG is that first of all, they're very idealized in a way. They're not the same as production code. So you could look at APG to kind of get an idea of where to start and how to use roles together, but it's not working code. It's not code that you can necessarily take and drop into a production system and have things be accessible. There's always sort of subtleties that you don't know until you actually test with users and with current browser support and current assistive technologies to sort of see, oh, okay, well, the APG suggested that role combination, but it actually doesn't work in this browser and AT pair that I need to support. So we have to do something else, or we have to try and detect that situation. So I think that there is a big difference when it comes to actually getting production ready code. The other thing is that the APG it's a reference, it's not a substitute for accessibility expertise in a person who does this as their job. So again, a point that I try to make is that it's a living field, and the APG is a great reference that I think a lot of accessibility specialists refer to, but it is not a replacement for a specialist. I think that it goes awry when people think that they can just look at that and then they don't need to actually work with an accessibility specialist. Particularly an accessibility specialist who has done the user testing to know what really works in practice.
Brian Kardell: I think that one of the things that hampers this is that it feels like we go in circles on some really common basic things, because the answer that we just need to make a native tabs element. I mean, I think that we should do that, but to tie this back with some other things that are happening in the web community, like part of OpenUI, Brad Frost had this idea for a global design system, which is like, 'Hey, what if we had something like APG, but with actual components, web components, why don't we have that?' And yeah, I don't really have a great answer why we don't have that. I've thought for a long time that we should have a kind of underwriters labs for web components, where we get experts to review and comment and say, these ones won't burn your house down. They won't poke your eye out. They won't accidentally electrocute you, and they'll work for people who have problems with vision or hearing or whatever. And also, I think when we look at the things that do get really widely adopted, people are trying to choose a proxy for expertise. So we figured, let's use material because surely Google has invested in making sure that these material components will be accessible, although that turns out to not be true. But okay, well, I hope it was fun and enlightening, and I hope we can solve some of these problems. If you have ideas about how we can solve the problems, let us know. If you work at Google and you can hire more accessibility people, that would be great. If you want to fund some independent accessibility work, you can reach out to Igalia is a good company for that.
Eric Meyer
Brian Kardell
Alice Boxhall
Valerie Young