5 ms·

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wo

The performance point in your linked post is worth highlighting: I see a lot of developers complaining "if the web had an accessibility API for this, then it wouldn't be a problem." The web does have an accessibility API. It's called the DOM. What developers are upset about is that they have to make their apps performant in that accessibility layer. The DOM restricts you from developing a fast app for sighted users and a much laggier less-featured app for users using the accessibility API, because it forces you to always have the accessibility API turned on. It forces you to treat the accessibility API as your default rendering target (and allows you to occasionally make something inaccessible by embedding a canvas element inside of that UI for one or two parts of your app. And if you can't develop a fast app using the accessibility API, then having a toggle to turn that layer off is not really a solution for that problem. I'm very glad AccessKit exists, it's better than nothing, but that doesn't mean the apps that are using it should be proud of themselves.

chrismorgan 4y ago
The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve misunderstood how various platforms work.) Browsers seem to have resisted adding fundamental alternatives of construct-on-query accessibility trees, or some kind of “I need AT stuff” switch so you can skip setting ARIA attributes or materialising other DOM if it’s not going to be used. The end result is that the web doesn’t properly support accessible virtualised scrolling (where you have a hundred thousand emails in a mailbox, but only render the ones on screen, still providing a meaningful scrollbar) or infinite scrolling. There’s role=feed which improves matters in most screen reader configurations, but it’s still making some compromises. But then, virtualised scrolling is imperfect even for non-AT use—things like browser find-in-page won’t work properly. Still more of the “if you want it to work properly, it has to exist in the DOM all the time” stuff.
- mwcampbell 4y ago
  You're completely right about platform-native accessibility APIs. To be honest, AccessKit itself doesn't support lazy accessibility trees for virtualized scrolling, at least not yet. It can avoid constructing the accessibility tree completely if the platform accessibility API isn't queried at all, but there isn't yet a way to only partially construct an accessibility tree while indicating that there's more available on demand. So to some extent, I guess AccessKit brings this web performance problem to native.
- danShumway 4y ago
  Okay, that is a fair point on virtualized scrolling, and while I can somewhat point to reasons why that's the case they're not strictly related to accessibility. They're more an API/extension concern than an accessibility concern, I guess. That being said... I have also kind of soured on virtualized scrolling over time as I've spent more time working on UX projects, and I realize that sort of sounds like an excuse (we don't support this well, but you shouldn't be doing it anyway), but... I do kind of feel like infinite scrolling and giant lists of elements to the point where the list needs to be virtualized is bad UX for most apps. ---- And to be clear, I'm not necessarily saying that the DOM is perfect as an accessibility tree, just that it's good enough compared to the kinds of accessibility APIs that most native devs want when they complain about the DOM. In practice, a full-featured accessibility API with the same feature-set as the DOM and the same level of capabilities would likely have performance costs no matter how it was implemented in the browser. Sure it could be better. But also all of those improvements could just be added to the DOM instead of making a new native web API. The biggest difference between adding those improvements to the DOM vs reconstructing something very similar to the DOM as a separate browser API is that devs could ignore the performance costs of that API and only benchmark their apps with the accessibility API turned off. And I think it's good for devs not to have that option (or at least, for browsers themselves not to directly provide that option; again I'm not saying that I don't think AccessKit should exist).

chrismorgan 4y ago

The crux of the web’s accessibility performance problem (minor in general, but major once you try to add accessibility to a canvas) is that it requires that everything be materialised at once and ahead of time, regardless of whether it’s being used. By contrast, the browser itself is able to lazily and (on most or all platforms, I believe) partially construct the accessibility tree. (mwcampbell can correct me if I’ve misunderstood how various platforms work.) Browsers seem to have resisted adding fundamental alternatives of construct-on-query accessibility trees, or some kind of “I need AT stuff” switch so you can skip setting ARIA attributes or materialising other DOM if it’s not going to be used. The end result is that the web doesn’t properly support accessible virtualised scrolling (where you have a hundred thousand emails in a mailbox, but only render the ones on screen, still providing a meaningful scrollbar) or infinite scrolling. There’s role=feed which improves matters in most screen reader configurations, but it’s still making some compromises. But then, virtualised scrolling is imperfect even for non-AT use—things like browser find-in-page won’t work properly. Still more of the “if you want it to work properly, it has to exist in the DOM all the time” stuff.

mwcampbell 4y ago
You're completely right about platform-native accessibility APIs. To be honest, AccessKit itself doesn't support lazy accessibility trees for virtualized scrolling, at least not yet. It can avoid constructing the accessibility tree completely if the platform accessibility API isn't queried at all, but there isn't yet a way to only partially construct an accessibility tree while indicating that there's more available on demand. So to some extent, I guess AccessKit brings this web performance problem to native.
danShumway 4y ago
Okay, that is a fair point on virtualized scrolling, and while I can somewhat point to reasons why that's the case they're not strictly related to accessibility. They're more an API/extension concern than an accessibility concern, I guess. That being said... I have also kind of soured on virtualized scrolling over time as I've spent more time working on UX projects, and I realize that sort of sounds like an excuse (we don't support this well, but you shouldn't be doing it anyway), but... I do kind of feel like infinite scrolling and giant lists of elements to the point where the list needs to be virtualized is bad UX for most apps. ---- And to be clear, I'm not necessarily saying that the DOM is perfect as an accessibility tree, just that it's good enough compared to the kinds of accessibility APIs that most native devs want when they complain about the DOM. In practice, a full-featured accessibility API with the same feature-set as the DOM and the same level of capabilities would likely have performance costs no matter how it was implemented in the browser. Sure it could be better. But also all of those improvements could just be added to the DOM instead of making a new native web API. The biggest difference between adding those improvements to the DOM vs reconstructing something very similar to the DOM as a separate browser API is that devs could ignore the performance costs of that API and only benchmark their apps with the accessibility API turned off. And I think it's good for devs not to have that option (or at least, for browsers themselves not to directly provide that option; again I'm not saying that I don't think AccessKit should exist).