Skip to content

2026 How can browsers help meet WCAG?

Jump to bottom Edit New page
Manuel Rego edited this page Jul 15, 2026 · 1 revision

WEH 2026 - How can browsers help meet WCAG?

Notes

Questions / thoughts?

AB: On the ETSI 301 549 (EU accessibility requirements), I was curious about comparing with the earlier session on monday. I wonder if there's something similar in the CRA.

DM: The EU accessibility act applies to websites and software in EU. I'm not quite sure what's the similar discussion. They do have requirements for browsers, not as clearly as in the EU accessibility act. There might be differences between CRA and EAA. Browsers are not as pointed out but they're covered under non-web software.

AB: So they're considered generic non-web software, as opposed to the special status in the CRA. Might've been good to have a special status since browsers are a key piece of software.

DM: There's the concept of underlying platform, so the website's underlying platform would be the browser, but the underlying platform of the browser would be the OS.

SP: The DevTools thing is implemented in Firefox afaict, the bounds are exposed if you hover in the a11y tree and same for the tab order.

DM: I assume you hover and you see the whole subtree?

SP: In the a11y tab, if you hover nodes ??

VY: That's very cool (shares screen) and there's a show tab order button. Do you see landmark regions?

SP: You can select any node in the a11y tree.

VY: Yea devtools have different features, you don't have the a11y name calculation steps no?

AB: No, you can see the column but not where it came from.

LO: Might be worth surveying through MDN via the WebDX CG. It'd be a good way to get developer feedback.

DR: From a framework POV it'd be great to get access to the a11y tree in trusted domains. We can force it into people's faces if we can access it from our devtools (not in an extension).

We can log a11y failures in the browsers. That requires people to look in DevTools. Many devs ignore the console. As frameworks we can provide big red banners in the CLI or in the page they're rendering. We can direct people to the a11y devtools.

One thing I'd like would be the ability to introspect and get the accessibility devtools. We can do with AX but it might be better if we could do that.

KC: I used to work on this website we're demoing right now and I have opinions. If you look at the console there are some warnings. If you're a developer working on GH there are some extra devtools, but there's a lot of noise and very low signal.

The errors devs look at are the Sentry-like stuff. We have CSP reports that point to an endpoints. We could do the same for a11y / html violation. I've discussed with the chrome team before because console warnings don't offer much value to developers.

GitHub is very on top of a11y and I'm sure they'd be more than happy to provide tons of feedback.

MA: Want to switch topics. One particular theme would be very useful (the keyboard users navigating sections and stuff). Found myself implementing a lot of custom solutions, so there's a header with so many options and elements and a sidebar with over 300 elements to select and a footer with so many more elements. We have tons of custom solutions to allow keyboard users to skip parts of our websites to get into the main content faster. Most solutions gathered are effectively hacks. Would be very useful if we had access to the html elements so users can select the same way screen readers navigate. No concrete proposal right now but out of the list of suggested improvements that stood out to me.

DM: I'd love this one moving forward, this is one of the most difficult. I think you said you implemented something already? But in any case...

MA: Yeah some hacks, with JS we prevent the tab navigation in the sidebar but allowing arrow keys. So if you tab you go to the main element because there's a way of skipping the sidebar. We have all these custom solutions because

Emilio: I think there are some proposals flying by related to this? Focusgroup in particular. But yea I think there’s a common pattern. In the FIrefox UI we have this as well, tab will navigate between toolbar sections. Like tab will get you to the arrow buttons, then URL bar, then bookmarks for example. I don’t know if it does the arrow keys automatoically (various people: yea).

Matthew: I'm one of the co-chairs of APA, on the TAG with Lola. Great presentation. Focusgroup is very cool but I don't think it's a whole solution. If you want to see a prototype, I have a browser extension that does the landmark stuff (exposes landmark navigation to keyboard users). Just want to echo the sentiment of making stuff really visible. We want to put this at the forefront of people's minds. I'll put a link in the channel.

KC: I'd like to point out that OpenUI CG is focused on resolving a lot of these long-standing missing features. Popover / custom select / focusgroup / interest invokers (tooltip) / menu elements. Many open proposals and it's a CG so anyone is welcome to get involved.

John: Making sure I understand what daniel was asking for introspection on the a11y tree. Security / fingerprinting might be a reason to do this? If done safely it'd be an incredible too.

Alice: Part of what I worked at Google was that. We ended up taking a step away from that for various reasons because AT detection. There's many ways of doing AT detection already but this is a very tangible direct benefit to users. Another part is just that spinning up the a11y tree it adds a lot of computation to the page. If you're just spinning it up to make assertions about it, and there's no great way of knowing when to turn it off etc. So there's a huge runtime cost. But trying to make the case to ship it was hard. Valerie is doing the webdriver protocol for at.

Cyns: The privacy / AT detection concerns were a big part of it. Disability status is sensitive PII. There are ways of guessing but this would be direct. Making it accessible to testing tools etc is possible.

DR: I know it's possible with a browser extension, but that moves it away to a panel. But maybe local-origin only? All the benefits would be there, there'd be no sensitive information there. Not sure there's appetite for more narrowly scoping it. We expose some stuff to local origin only.

zcorpan: I was going to suggest usign the webdriver thing. Is there a reason webdriver is not an option?

DR: I'm trying to make it as seamless as possible to get the information even when they don't want it. Running a testsuite that uses python is something they'd have to do. We expose so much information when devs use their own website. Not just a11y, all kinds of stuff. That's the place where our devs are living. There are other solutions but they all add friction and make people not care.

zcorpan: I'm not suggesting to run a test-suite, webdriver is an API. If you're developing a website and spinning a website I can spin a webdriver-enabled browsers and do assertions on it.

Valerie: I don't think WebDriver does what you want? It does expose the a11y tree but doesn't tell you about errors. Is there a11y node for this element and if so it returns. There's also the DevTools protocol which also exposes this. I don't understand, you want this outside of the browser, how would this enter your tooling.

DR: I come from a very particular perspective. We have particular devtools (not browser tools) which run in the browser. So you can do very cool things like click on a component and open it in your IDE. We can expose everything about the build and expose a lot of stuff. Very cool if I may say so myself. What I'd like to do is, from there, within the page, to introspect yourself to expose introspection / errors in the page.

Alice: Maybe we could expose the DevTools protocol exposed in localhost? That would be not privacy / performance sensitive?

Patak: One comment to what daniel was saying. Nuxt devtools are now the Vite devtools have the same capabilities so lots of front-end devs would be able to use these.

zcorpan: Localhost is probably not a workable security boundary. There's use cases where users use localhost and having a separate security profile / attack surface for localhost won't pass security review for browsers. Maybe a CLI flag or so? There are no APIs available to JS? But we could provide it.

emilio: maybe through origin trial.. do these frameworks, do you map a domain to localhost?

KC: An extension would maybe be able to expose DevTools requests to the page?

emilio: I thought an extension wouldn't work for this?

KC: I think the issue is more of the interface.

emilio: Was thinking more of the way WebMiDi stuff is exposed in FF, which you can install on any origin.

daniel m: there are accessility testing tools with browser extensions, maybe they could do what is being discussed. We aren't going to solve it now, but we should follow up. One is the bigger picture, like keyboard access and contrast improvements, we might not have the right people to make decisions on. But there are these smaller projects, how to detect ARIA errors.

emilio: Another thing we could do is, we have APIs for performance reporting, and other things Keith mentioned for CSP. What errors you want to expose.. if we expose them to page in scriptable way. Like accessibility of thing.. error reports.. still need to turn on accessibiltiy tree... it's not expensive for local development. As expensive as turning on devtools.

simon: how do you make the API available

daniel R: we avoid exposing APIs that will give you fingerprinting...

emilio: you need accessibility on for these errors.

daniel R: from my point of view, running with a flag or installing a extension, it's second best. But the developers who need it most are the people who won't do that. What about a popup that asks if you can turn on accessibility?

daniel M: there are some ways to guide the process towards this. I get the people will not be willing to install an extension.

KC: We touched a few times of it being expensive to run the a11y engine. You can very easily find out that aria-hidden is in a focusable element. That does not require the a11y engine for that kind of stuff.

Alice: I think you can do that with axe.

John: Yeah I think the category you're talking about we're doing well, it's the ones that need the while a11y tree.

Alice: Maybe revisiting a way we can provide this info via something like WebDriver or DevTools etc to the page would be good.

John: Do people use matrix? we can start something and then find a venue.

John: You were curious about browsers and contrast?

Daniel M: There's HCM but there's also other contrast user needs. Sometimes it's the opposite. Making it easier for users so that it respects low contrast mode might be good?

John: So like prefers-color-scheme?

emilio: Firefox uses HCM / forced colors to expose low-contrast mode as well and infers prefers-color-scheme / prefers-contrast values.

Cyns: user stylesheets could also work?

zcorpan: Wanted to brainstorm things we could do to fix a11y issues. Are there other things browsers could automatically fix or address? Like generating alt text.

Daniel m: Chrome has some automated alt-text stuff I think? It's possible.

Alice: Related meta topic: A lot of these were great. Some I've heard but some are new. But the problem is getting that shipped. There's a disconnect between web people and a11y people, which doesn't make a lot of sense, like people sitting literally at different rooms @TPAC. Are these ideas tracked somewhere like in a WG, and are there bugs tracked linked to those ideas?

Daniel m: Re. browser bugs yes I agree, sometimes a11y is not treated as a web engineering discipline which doesn't help.

Alice: And vice versa

Daniel m: In terms of whether these things are tracked or not there are a lot of work in ?? Task Force. They're now in "writing requirements" mode rather than "researching".

Cyns: Are these into WCAG?

Daniel m: The intent is to put something in WCAG 3 but not sure when.

Lola: Just wanted to answer simon's question. The web aim survey for 2026 the most common error was low contrast text specifically with 83.9% websites hit. Colour issues may be outside the responsibility of a browser but empty link / buttons can be addressed perhaps?

emilio: There are thing like stroking low-contrast text, i can write an extension that can do that with some accuracy. But it doesn’t impossible to do that kind of stuff in the engine. Might be worth prototyping?

Cynth: I think there’s a lot of opportuinty for user stylesheets because it has never been realised. Users aren’t going to write CSS but the browser could use user stylesheets under the hood.

Emilio: there are some features that do that in Firefoz hat do that. Firefox has a checkbox to always underline links. If you check that it’s basically setting text-decoration: underline !important. FOr simple things like that it’s a great fit. Yea so I think there’s a lot of potential. Sometimes it might be hard for a browser to overwrite website styles.

DM: Thank you all for joining!

Valerie: Thanks John for a room (#accessibility-tree-api:matrix.org).

https://www.webengineshackfest.org/

Add a custom sidebar

Clone this wiki locally