Room 402: Hello, everyone. Welcome to this breakout session at TPAC 2025. This is a session on capability, accessibility capabilities in, post-source code and content, a report by the community group Accessibility at the Edge, A11YEDGE. It is our report. It is just published.

Room 402: And we're really excited to talk with you about it, and about its implications for our ongoing work in web standards. My name is Janina Saika. I am the editor of this report. I'm also one of the authors, and I am joined today by two of our three additional co-authors who will help us first look at what we have done, what the report includes, and how we organize our information, after which we will turn to question and answer, and hope to have a wonderful discussion with you. So welcome, whether you're here in person or listening after the fact on the recording. We're glad you're here, and we'd like to continue the conversation with you today. And… post-event. We will first… I will first provide a brief overview of what this report sets out to do. Lionel Wolberger will take us through the structure of the report, what it looks like, and then Jason Taylor from… Lionel is with Level Access. Jason Taylor with Usable.net will take us through the methodology that we systematically follow in our evaluations that we address in our report, how we came up with that, what it is we are attempting to do with that. He's the one that kept our feet to the fire as we were authoring this, and kept reminding us what our purpose was, and kept us from straying, so I can't think of anybody else better to talk methodology with us all. At that point, I think we'll be ready to take up questions and comments and go forward. So, this work began some 4 years ago.

Room 402: There is something in accessibility called overlays that has been highly controversial, because there have been some very unfortunate practices engaged by some in the industry that are misrepresenting what is achievable with what they are selling, and that has made a lot of people really upset, and justifiably so. However, where we found some concern in those of us that worked on this report in the community group, was that we perhaps were misrepresenting technology to say that therefore anything one did beyond source content in the way of remediating accessibility was inherently and intrinsically inappropriate. Evil, inappropriate, whichever.

Room 402: I think those of us working here don't believe that technology is intrinsically good or intrinsically bad, in terms of any moral value. You can do bad things with good technology, and you can certainly do good things with even… questionable, marginable technology, though it's better to have robust, strong technology. So, the question in our minds was, are there things that Post-Source can do as well, maybe even better, let's document what we think is achievable, and let's have an honest look at what we can say about that to the best of our abilities, take that to the community, and take the implications where they will take us, based on that analysis. So with that.

Room 402: We set out to do that. We went through an iteration of everything we could think of, both in terms of looking at content, presenting content to users, that Post-Source might have an impact on, might already be in use on, or aspirationally could perhaps in the future have an impact on. And we talk about those things. Lionel will be showing those to us momentarily. We look to both the content of this, the presentation to users, but also on how post-source opportunities may be used by organizations in the management and the conduct of business. So there are those various sections to the report. So with that as a structure of where we started some years back, we've gone through several iterations. An earlier version that was the main report has now become an appendix. kind of a historical value. With the assistance of the Information Architecture Community Group, we have changed the structure of this document several times, but we are fairly pleased with it as it stands. So, without further ado, Lionel, please take us through the actual, Report.

Lionel Wolberger: Sure, so, we didn't… we have the… we did not actually prepare slides, so I'm just going to share screen and show the report at its published URL, which I've already put into the minutes. And I'll just, fly us over the structure. As we gathered capabilities over the 3 years that we were curating this report, the number of capabilities rose fairly quickly. There's around 75 of them currently in the report, and we needed to chunk them in a way that would be useful to the reader. We ended up organizing it in a way that mirrors classic web architecture. We separate structure, style, and behavior in the classic stack of HTML, CSS, and JavaScript. So section… of course, section number one is the introduction. We… I don't need to dwell on that. Oh, but in the introduction, we, take care of some important aspects of post-source. and provide some pointers to, for example, privacy and WCAG outcomes. But then, the first section in the layer Number two is content. We wrote preferably HTML. It focuses on structural markup and information, text, images, rich media, and deals with foundational, features.

Lionel Wolberger: The next section is presentation, CSS. It covers user-driven visual adaptations. That's the The widgets that we see on the web that allow changing text styling, color contrast, this ends up being the largest section Due to that reason. And then the third section is functionality, preferably done in JavaScript, and here we deal with dynamic behaviors, event handling, notifications, form navigation.

Lionel Wolberger: Having that three-layer, format, we realized that there were kind of a meta-layer of managing your website. You have web or digital properties that you manage, and sometimes the Edge was very useful for that, of, for example, to monitor what your site is actually being experienced as. So we put that in under a management heading. And lastly, as we gathered these capabilities, we found that some of them were very very forward-looking. They were worth capturing, but they weren't quite achievable today. For example, Agentic AI is… we are seeing a lot of AI now, at the edge, in the users. possession in the user's assistive technology, and so we made an aspirational section. And then there are some appendices.

Lionel Wolberger: That explains the structure, the buckets into which we sorted things. And then the other aspect of the design of the report, which deserves highlighting in this introduction, is the, how we evaluated each capability. So, each capability is considered from four perspectives. So, for example, I mentioned, changing text size. We first say source. And we spell out how the original source code Could be involved in doing this capability. And then trade-offs. We examine the implications. Let's say you don't want to do it in source. So you'll find, throughout the document, we mirror what we found our community, the accessibility community, is stating, which is. that source should be your first thought. Get your source code correct. And so, we have a section of trade-offs. What are you perhaps giving up? And as Janina hinted, we did find that some capabilities are better at the edge. Some capabilities, perhaps, can only be done at the edge. Then benefit, we spell out that benefit if there is one. And finally, automatability. A word we cobbled together, not a word you hear frequently, but we wish to express, in short, at a glance, whether doing this at the edge, is amenable to automation.

Lionel Wolberger: And again, one reason we did that was we felt we were addressing the wider community's concern, particularly with automation and poorly done automation. One of the themes of overlay, distress was that they were doing things in an automated way that was perhaps, had false positives, or was poorly done. And so, this is the only of those four perspectives, that we actually have a coded set of of responses. It could be in many cases, in some cases, in no significant way, and does not apply.

Lionel Wolberger: So, Janina, if you feel I've covered the introduction… actually, I'm realizing there is a diagram, perhaps it's worth looking at the diagram.

Room 402: Yeah, it's worth thinking of, let's do the diagram, and yes, that's perfect introduction, Lionel, thank you, but let's do the diagram, because I think that will really help people.

Lionel Wolberger: All right, then as my last component of introducing the document, there is a diagram, positioned in the middle. It's Figure 1, labeled Fundamental Diagram of Dataflow. And this diagram also changed quite a bit over the 3 years that we worked in the report, and it has some subtlety, which it's my privilege to point out. So, at the top of the diagram, it says 1, source. Content slash code. With this rectangle, we're expressing everything that we expect to be done in source. If you are coding a digital experience, this is your source code, this is how you prepare this to be consumed by visitors. And all the way at the bottom, user. user, and we wrote here EG browser plus assistive technology, etc. The et cetera refers to browser extensions, whatever is happening at the user's side. And that, again, is the same colored rectangle. So, these are the two extremes, and the simplest model we have of digital experience delivery. There is a source. that the user accesses through URI, like, if I may, cnn.com. That accesses a source, and then code is delivered down this pipe, this vertical line.

Lionel Wolberger: Now, on the vertical line, there are two major areas, two clouds. First one, closest to the source is source authorized. To stick with my example, that news company probably is hosting some advertisements. So they put a JavaScript code and they authorize that somewhere along the line from other sources is added advertisements. So that's post-source. The source may contract with a CDN. to cache local copies of their source to be delivered closer to where people are located. So we drew here CDN. And otherwise, we just drew a generic post source, post source, post source. But these post sources are authorized by the content host.

Lionel Wolberger: So if I mentioned an advertisement. Real-time bidding system is probably added, a common system, and the list goes on. We found evidence that we relay that some sites have up to 90 source-authorized editions that happen as it's being delivered. And then, in the bottom cloud, it's user authorized. I was just using, yesterday, an extension made by an accessibility provider that when you load a page into your browser, you can then assess it by a set of automated tools. So that's a user-authorized, post-source manipulation. And here, we wrote post-source, post-source again, to simplify, but we also wrote proxy, because many users access the web through a proxy, and some of these proxies are actually active, and they flag things, and they manipulate the data coming through. So that concludes a quick look at the diagram, the only diagram in the document called the Fundamental Diagram of Data Flow.

Room 402: Thank you, Lionel. It really illustrates our thinking as we progressed and wrote the report of how we saw this interaction between content that someone is making available online and the user at the other end that is hopefully consuming it happily and comfortably, which is what accessibility is about, in our view. Two key points here. One of the things we realized as we worked on this report that is captured verbally in the introduction a couple of times, but also in, I think, our first set aside note, we believe that all of the capability adaptations that a user might want to apply can be delivered without on-screen widgets.

Room 402: Those are not intrinsically necessary anywhere. They may be there, they may be useful for some and obstructorous to others, but they are not essential. Lastly, and most important, in terms of judging whether an outcome is effective. and delivers good accessibility or not, we wrap ourselves fully and unambiguously in the web content accessibility guidelines in WCAG, because to our… assessment. It doesn't matter where the remediation occurs, WCAG is still the yardstick by which we judge. failure or success. So, with that, those two additional comments on what Lionel just showed, Jason, may I ask you to talk about our methodology a bit more before we go to questions and answers and further discussion?

Jason Taylor: Yeah, I'll be brief, because I feel, you both have done a great job of explaining the structure of how the report is basically put together, I'll probably just pull out things that you highlighted. When you look at this report, capabilities are very much aligned with outcomes under the WCAG. What is the outcome that the capability can achieve? I think what you just outlined there, in terms of this is a… this is about delivering, to the browser a, unified code. That doesn't require any special UI pop-ups or control panels to deliver the outcome.

Jason Taylor: Lionel touched on, how each capability is essentially… has, sort of, four subgroups. I might reword the source. What we've tried to emphasize on the source is.

Room 402: How can a…

Jason Taylor: Potential, inaccessible experience, be achieved? In source, so essentially, what is the… What is the potential practical reason why a element is not available or not correctly coded? The trade-off is always gonna be focused on Essentially, we… strongly believe that if this can be done in source, you should do it in source. But I think the trade-offs, emphasize that if you're… if you're doing this after the fact. What type of things you need to take into account, in terms of structure, reliability, consistency, and robustness.

Jason Taylor: When it comes to benefits, we're looking there around, The primary benefit of delivering accessibility when it's not primarily supported in the original code. And then, a word on automation. Again, I think that, Lionel's riding, talking about the negativity that has been associated with Used in any type of post source. Jason Taylor: Has been, around the 104 focus on trying to remove humans from the process, so I think we are trying to emphasize that whether it's post-source or in-source, the same sort of yardstick exists. You need good development, you need good testing, you need good user testing. to achieve a proper accessibility outcome. This is not magic. It doesn't happen without good development and good architectural understanding of what needs to be done.

Jason Taylor: There isn't really a shortcut to good accessibility, whether you're doing it in post or whether you're doing it in the original source. And I think that we've tried to stay true to those types of methodologies when we talk about, how these capabilities can be achieved. In post source.

Room 402: Want to say a word about automatability, Jason?

Jason Taylor: That's what I was saying, automatability, as I… That was my point about automatability, but… web accessibility, whether you're doing it in source and you're using some automation to help you, or whether you're doing it post-source, it… it requires good development practices, good development processes, and automation is not a magic bullet, and we don't describe it as such.

Room 402: Thank you very much. As we worked on this. We didn't note many times ourselves saying the same thing. No particular benefit to doing this post-source. We found that more than once. We also found sometimes that there were things that you could do post-source that would not easily be done in source. So we've got both happening. We haven't counted those up. I thought it would be an interesting exercise to go through and flag the ones. We have plenty of ID refs in the document, so it'd be easy to build up another table of contents. Here are the… here are the ones where we saw no particular benefit, and here are the ones where we said, no, there actually is a big difference to what is achievable, posters. Haven't done that yet, but I expect at some point here in the not-too-distant future, that will be an interesting exercise. Anyway, I want to go to the room. We have good participation here in Japan, in Kobe, and I want to hear from people who have taken the time to join us.

Room 402: So, as we turn this open to a conversation, let me say we'd like to use our, if you can, join IRC. Our room is hash A11YEDGE. Accessibility spelled A11Y, EDGE, all one word, and if you Q-plus yourself, we will call on you in order as we go. And again, I want to remind everyone we're operating here under W3C's Code of Ethical Conduct. And, also be mindful of, intellectual property, you don't… want to be disclosing anything you shouldn't. So with that as a presentation, with that as an introduction. What should we talk about? Do we have a Q, Lionel?