Room 405: Okay. Thank you everyone for joining. This is a breakout called Building It In vs. Bolting It On, and it's about making accessible specs and updates to the accessibility horizontal review process. I'm Matthew Atkinson, we've got Fredrik, who's online.

Fredrik Fischer: Hello.

Room 405: And, we… I think we also have in the room Ananya, who's done some of the work that you're gonna see, coming up. Everybody, welcome, thank you for coming, lots of you here, much appreciated. And I think we're about ready to go.

Room 405: What we'll do is we're going to look at some changes that we have made in APA and TAG to make the horizontal review process, or just the review process in general, more accessible to spec authors. And we also wanted to talk a little bit about what APA can do for you in terms of what sort of advice we can give you. We want to talk a little bit about something that a number of you have come into contact with, the framework for accessibility in the specification of technologies, or FAST. Notably, I think a lot of people in the room have probably seen the checklist, and we're making some changes to that, and we also want to hear from you in terms of pain points that you have with the process, and, what sort of advice that you would like us to give.

Room 405: First of all, horizontal view, horizontal review, what is it? Well, it's, as you may know, there's a number of different areas, accessibility, internationalization, security, and privacy, where different specific groups with, expertise on those subjects give input in for spec authors, and we'll talk a little bit more about the shape of that with accessibility. But it's, as I said, peer review in those areas, that I listed. Accessibility, internationalization, privacy, security, and maybe architecture. I don't think TAG has consensus that it's a horizontal review group, but it kind of does fit into that vein of reviewing stuff and giving advice. Who is it for? It's for spec or explainer authors.

Room 405: TAG often gets things way before it becomes a spec, which is exactly the right time to be getting things, which is great. When does it happen? Often too late, from… especially from APA's perspective. We very rarely find out about stuff in a window where we could have a reasonable impact on it. So sometimes we do, but it really varies as to whether we find out about stuff in a timeframe where we could give advice that would have a significant effect. And I'll give some examples of some advice that we have given. Definitely we would love to hear about things earlier, and sometimes… sometimes in the official W3C process, we would only actually hear about stuff way after it's shipped, which is not good. Often the people involved will flag us and let us know about it beforehand, and it's much appreciated when people, and I know a number of you in this room, have done that when you have done that, so that's very much appreciated. What does it provide you with? Well, we'll talk a little bit more about that. There's, first of all, though, there's different ways to request a review, so when you make a request, you can, do a self-review, which is, like, the FAST checklist, or maybe the tag, the new tag one, which is, which we'll talk about. There's different ways to, request a review based on what level of… maturity in terms of the spec, process, that you're at. So, first public working draft, or perhaps you want to transition, and of course, if it's a transition request, it has certain timeframes associated with it, which we do our best to meet, and if it's FPWD, the timeframes are maybe a little bit more relaxed. However, it's much appreciated when we hear about stuff before the process says that we should, because, again providing input earlier is… it's much better for us to know what's going on, and for us to give our bias that might be of use. Because we hate to say no to things, even if we could say no. We would hate to say no to things, and the earlier the better.

Room 405: We actually are in the process of adding a couple more options to this, reasons why you might want to contact us, which relate to some of the work that I'm going to talk about next. But I just did want to give a sort of overview of where we are at at the moment, which does include some of the recent changes. If we think about your specification, there's a number of inputs into that, particularly from an accessibility perspective. Roughly, in the order in which they would happen, you've got the tag accessibility screener, which is… it used to be called Questionnaire, but it's now called a screener, the reason being, that it's to set it apart from more in-depth, questionnaires or checklists that exist. The screener is a super quick thing. To do some very high-level questions to give us a very high-level view, on what you're doing from an accessibility perspective.

Room 405: The FAST, which is the Framework for Accessibility and the Specification of Technologies, is this set of guidance that is being developed that we're going to talk about a bit more, in a bit more detail later on. The first checklist is the APA accessibility thing that you answer, that a lot of you have done self-reviews, that's what you've been looking at, and we have some updates in progress on that. And then also, you will, at some point, request horizontal review, and APA will review it and provide some input. And Behind a lot of those things are resources that we have developed within APA and between us and AGWIG, for example, including accessibility user requirements, which the Research Questions Task Force work on, and making content usable, which is a whole load of really cool guidance that the Cognitive Accessibility Task Force has worked on. And… resources like those, even if you haven't looked at them directly, they will feed into all this other stuff that we're, that we're providing in terms of questions, and when we give you reviews, and we say, have you considered somebody using it in this particular way, then those use cases often come from those documents or similar documents to those.

Room 405: When we do reviews, we learn stuff, like what sort of problems are you trying to solve, how are you solving them, does that result in any sort of new accessibility knowledge that we should include in our documents, and in our other deliverables. In much the same way that the TAG does reviews of everything, and comes up from those reviews with design principles, and then puts those into a design principles document that help you avoid problems in future. We're doing a similar thing in the sense that the things that we learn from the reviews that we do feed back into the use cases that we have, and the nature of the sort of questionnaires and things that we ask of you.

Room 405: So the main thing that we have there is use cases. And there's a number of documents that… I mentioned that weren't APA review, so the tag accessibility screener, there's, there's a link to this you can follow when you get the presentation. This is just an example of it. It's only 7 questions, and 2 of those are actually not guaranteed to be, sort of, triggered. So, it's between 5 and 7 questions, very, very high level. And we've just recently, or Ananya has just recently converted it to HTML, so it's a… how it works now is it's an HTML form, it will give you a GitHub issue that you can put into your repository, and then you can link to that from your tag design review request, or your APA review request, or whatever you want, and then you can say, here are the results, and it's much easier for you to provide them. We've seen, with the tag questionnaire, and also with the fast checklist, we've seen people making their own templates, or having all sorts of problems copying and pasting, and things not ending up in GitHub. We think it's a good idea for it to be in your repo, so that it's something that you own, then you can reference very easily. So, the screener we've updated to make it HTML. Likewise, Ananya's done the same thing with the FAST checklist, so… at the moment, the content is pretty much the same as what it was, but it's now in the form of an HTML form, and this again will give you a GitHub issue that you can put into your repo. And this one, because it might change over time, you can tick off the boxes as you meet the things in the checklist. So that's something that you can have as a living document for at least one, sort of, run-through of the lifecycle of your spec.

Room 405: And I mentioned these accessibility user requirements. There is a whole range of documents that are Llooking at how do you do accessibility in any particular technology domain. There are several. There's media, there's real-time communications, there's XR, there's synchronized media, there's all sorts of stuff. These are really high-level, really good use cases that need to be considered to make something actually usable in practice in one of these areas, and we're adding more all the time. There's more of these coming out, but they also get updated every so often, and they're really good. Collaborative Tools is another new one that we did, so that's, like, anything from online editing of documentation to revision control, that sort of thing. Really good set of resources, which… This is something that… that you're getting when we do a review, but you're also welcome to... I look at them and give feedback on them, of course. We also have… oh, there's a missing image there, that's interesting. The, making content usable for people with, cognitive and learning disabilities. This document, which you can follow the link to get to, is really helpful. It's very big. It's actually... There's been some work done to make it more accessible, actually, because there's so much in there, depending on who you are and what sort of problem you're trying to solve, there's a lot of different advice that you might want to, benefit from, and there's… it stretches the format of the limits of the TR format, so we actually did, or the way team made a much more guided version of it, which is more easy to consume, but the link here is to the TR version.

Room 405: And, the point is here, as I've said before, the key deliverable from us as an APA to you is use cases, and that's why it's a good idea to think about this stuff early on, because, that's when that sort of input is most valuable to you.

Room 405: Of course, there are other types of accessibility expertise that you might need. We also do have some very deeply technical people, like CSS people, we've got all sorts of stuff. There's an ARIA working group who is very much represented here, and we're talking with, ARIA later in the week as to how we can get the benefit of their expertise to you with, reviews. But use case is a big thing, and we often find that Lots of you have written really good accessibility consideration sections, and you want to do the stuff, and you're technically adept, but the one thing that is hard for people who aren't in accessibility, if you will, is realizing the breadth of use cases that exist out there. Again, that's why use cases is a big thing to us, and I will leave it there, on that topic, but I also wanted to talk a bit more about explainers and accessibility consideration sections. Then we're going to talk about the updates to the FAST, and then we will go over to you for feedback.

Room 405: There is a document which, is all about writing effective explainers, and it's a generally good document overall, and it's got some advice about accessibility consideration section in there, so that's why I would, recommend looking at it. Just wanted to highlight it in case people weren't aware of it. Also, there's an example accessibility considerations section here that we, put into the Compute Pressure API. Our very first, blush of reading the spec. It's a low-level spec, it's a JavaScript API, it gives you some information that's designed to be machine-readable, not really for people. Why does it need an accessibility consideration section? The section is written here, but I'll explain why, Why this one is so exciting.

Room 405: One of the things that they talk about a lot in the Compute Pressure API spec, as an example, one of the running examples, is video conferencing, video streaming, and… the API itself it's super low level, super simple, and very interesting, but, what's it got to do with accessibility? Well, it's about making decisions. It's about so you, as the web app, can make a decision about how you allocate resources. Because somebody's using it, and you want to optimize their experience, given what re… the resources that are available. So, it's actually got everything to do with accessibility, because it's to do with something that people are going to be affected by in the end. And one of the things that we realized is... An example that's given is, if you don't have the resources, you could drop some video streams. Seems like a perfectly reasonable thing to do. Except if one of the video streams is the sign interpreter, and that's the one that gets chosen to be dropped. So, what's the solution to this? Well, it isn't to put in a special API for, this is the accessibility video stream, obviously, because, as you will all know, that's a massive fingerprinting risk, it's super specific, it's… that's not the right solution, that's way too heavy-handed. But… One of the things that you can do is just ensure in your app that the user gets to choose to pin something. Doesn't matter what the reason is, it's up to them. If they can pin that stream, then you could say, well, don't drop that one, when you're making the decision.

Room 405: This isn't stuff that goes into the API, but it's considerations. It's a good example of a consideration for an app, which is making a decision, and it's showing that these decisions have ramifications, and potentially very big ones for people who are using it in a different way than you might imagine. So, that's why this example is really good, and it's actually a really empowering one. And one of the requirements in the real-time communications accessibility user requirements is exactly that, that somebody needs to build a PIN, a window or a video stream in apps that have that sort of nature. So that's just an example of how this gets through from being about this API to an accessibility consideration.

Room 405: Now, I'm going to hand over to Fredrik. I'll have to change the slides, Fredrik, because I'm sharing the screen, but this is about the fast.

Room 405: One second, I just queued to ask a question. In theory… Juanita.

Fredrik Fischer: Oh, hello, Juanita.

Room 405: Hello. I'm sorry. So essentially, with the API, I was wondering if there's gonna be a way for folks to flag, if they want to share the information, if they're using, let's say, a screen reader, and that obviously slows their experience down, or they're using, even if they're, in a country where that's on 2G or 3G service, If you could actually flag, to give a flag to say, hey, get rid of all content that's gonna slow my experience down.

Room 405: That is a really interesting question. I think we should come back to it after the slides, and there's a lot of interesting stuff in there. But let's just go through the rest of the slides, and I think then we'll come back to it, because I suspect that might be a good discussion point for later, if that's alright. Cool, thank you. So, Fredrik, about the FAST…

Fredrik Fischer: Yes, about the FAST. The FAST is... The advice that is, written in the Compute Pressure API accessibility considerations is actually a very good manifestation of what we are trying to nudge spec writers into providing by creating the FAST. The FAST is based on 2 legs, or pillars, if you will. Those being user needs, that's very concrete stuff like, a person needing some information of what a UI control does, or is. And then functional needs. or capabilities, which is a, term we've had lots of trouble explaining. That could be color perception, that could be, different, other, other kinds of sensory or mental load, properties of a person. Or what have you, it's, the capabilities, I think, captures, what it's about. It's what… what, sort of, how the user interfaces with the, digital environment.

Fredrik Fischer: The intersection of user needs and capabilities is where, FAST, as concretely as possible, we hope, will provide advice. And there's quite a lot of those intersections. However, because of different developments, not the least of which being that the FAST advice was too abstract, and also because of the developments in in the, well, without the W3C, like in the digital accessibility framework, which is created by former and current members of the W3C who are doing this, sort of parallel to their W3C activity; we have found ourselves in a quite an improved situation actually, informationally and precisionly, so to say. So we are rebooting the FAST. FAST boot if you will, to make it even more W3C-specific, because this was one of the issues we had, that we sort of drifted off into a very academic and abstract place.

Fredrik Fischer: Let's look at which persons may, or which actors, to borrow the term, use the actual terminology, may be involved in and maybe relevant for the FAST. That's the spec itself, of course. That could also be any technical document. You have the author. You've got the user agent, the… any kind of assistive technologies, and then, of course, the user.

Fredrik Fischer: We have an example here on a slide, I don't know if you're caught up, Matthew, I can't see, but, so looking at alternative content. The Author is… the spec should, include provisions for alternative content. Authors should provide said alternative content, meaning alternative texts, or alternative audio streams, or video streams. The user agent should expose that context, that content. AT should render the contents in a consumable way and the user should be aware of possible content. Well, actually, the AT's task would maybe also to make the user aware of said content. There's also some additional Actors...

Fredrik Fischer: Could I just add something there, Fredrik? As I mentioned,

Room 405: I just wanted to say we're not necessarily talking about the alt attribute here, although we could be. In the world we live in, that's what we're talking about, but there's nothing to say that's necessarily how it had to be done. There's other… and in other sort of standards, you don't have that attribute, for example. We're talking about the idea about providing alternative content. The alt attribute is the poster child example of all these things, which is an example I think everybody could relate to what the spec is doing, what the author is doing, all that sort of stuff, but for example, the UA, it could have been decided that UAs display the alt text visibly. It could have been. It wasn't, but, that is something that could have happened, and so we're trying to be a lot more concrete in terms of the actors involved, but we're not being totally prescriptive as to how we think things should be done, because that's still up to you as spec authors. Thanks for the indulgence, Fredrik. I'll move on to the next slide.

Fredrik Fischer: No, of course. And also, on the topic of alternative content, not to push that too far, but of course, media queries is an area where alternative content may come into play, quite profoundly, if you will, with alternative video streams, alternative audio streams, and how that could be built. Also, the synchronization of streams, which is a topic we've been, going rather deeply into in APA discussions.

Fredrik Fischer: Yes, and right. We'd like to support you in all kinds of promotion, of accessibility of your spec. Both, in authoring tools, and authoring processes associated with a spec. How you can provide a more accessible way of creating your spec. Also, of course, the products that result from the spec, and the spec document itself, which is an area where we have a lot of, sometimes a lot of work to do. And now I'm handing back to you.

Room 405: Cool, thank you very much, Fredrik. I just want to mention a couple of things about where's WCAG in all of this? Because, following, WCAG, of course, is something we encourage everybody to do, and it provides a baseline level of accessibility for web content. And, of course, many of the principles in WCAG you can apply to lots of other things as well, including specs and the, some of the examples that we've given. But the coverage of WCAG in this, context is not necessarily universal, because we can only make recommendations, based on what we know works for, web content, and there are some things that are outside of WCAG that this might cover. The accessibility user requirements, for example, are application domain specific, so they can say: you need to be able to pin a window, but that applies to a video streaming thing, but it doesn't apply to every website, so obviously it's not in WCAG. So FAST is a way to generalize that a bit, but still be talking in terms of the concrete actors that we've talked about, and hopefully help you make considerations when you're adding stuff to the platform.

Room 405: Just very briefly on APA's goals, just to recap. So, we want to be available as early as possible, and we're doing stuff as described to try to make it easier to get in touch with us and have, involvement as early as possible. We think that one of the main things we can do to help is highlight use cases, but we also want to channel advice from other technical areas as well. We... I just said that point. Also, one thing that we do… we used to do this on our wiki, but it's moved recently to GitHub with all the rest of the processes. We do longitudinal tracking of specs accessibility, so whenever we review a new version of a spec, we probably… if it's had any sort of longevity, we will have wiki entries going back on it for several years to see what's changed over the years, and we're doing this now in GitHub, but we find that's quite useful for helping us. What did we raise last time, what's changed, that sort of thing. And when we get change logs, which a number of you give us with reviews, it's super appreciated, because it's very helpful with that.

Room 405: And then also, we want to try and improve horizontal review process for everybody where we can, so we've done… we've suggested some tweaks, we're in the process of suggesting some more tweaks to make the process more consistent across different review groups, and we've worked on things like alternative interfaces to the process as well. There's a link there to a command line thingy.

Room 405: So now we want to go on to the most important part, which is hearing from you as to what the pain points are in the process. I can imagine what some of them would be, and we'll do our best to speed up. If you've got anybody in your organizations that is wanting to learn about accessibility, please send them to us, because we will teach them, and then they will do reviews, and it will be great. And what sort of advice you would like to see in the outputs that we give you. And so I will stop the recording so that we can then go on to having that group discussion.