4 ms·
> A core premise of Cocoa, and MVC in general, is that UIs are a projection of data into a different form of data, specifically bits on a screen. This is a tan
by mwcampbell 4y ago
> A core premise of Cocoa, and MVC in general, is that UIs are a projection of data into a different form of data, specifically bits on a screen.
This is a tangent, but the implicit assumption that the UI is visual is just begging for a response from an accessibility perspective, so here goes.
Accessibility is very much an afterthought in native GUIs, not only in Cocoa, but also in Windows with the UI Automation API, and AFAIK with other native accessibility APIs as well. With these APIs, the assistive technology (e.g. screen reader) pulls information from the application (usually via the GUI toolkit), through repeated calls to methods defined by the accessibility API. Often the AT has to do several such calls in a row (and those often translate to multiple IPC round trips, making things slow). And the UI might change between such calls; there's no guaranteed way to get a consistent snapshot of the whole thing, as there is with a visual frame. On the application/toolkit side, these methods may return different responses from one call to the next, and the application or toolkit has to fire the right events when things change.
The web improves on this, in that accessibility information is conveyed through HTML tags and attributes. And yes, this is included in the output of a React component's render function. So while in practice, implementing accessibility may still be an afterthought, it's not an architectural afterthought as it is in native platforms.
One of my goals in AccessKit [1] is to work around this shortcoming of native accessibility APIs, particularly for developers of cross-platform non-web GUI toolkits. In AccessKit, the toolkit pushes a full or incremental accessibility tree update to the AccessKit platform adapter, which maintains the full tree in memory and uses that to implement the platform accessibility API. This even works for immediate-mode GUIs, as one can see in my proof-of-concept integration with the Rust egui toolkit [2].
[1]: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
[2]: https://github.com/mwcampbell/egui/tree/accesskit https://github.com/mwcampbell/egui/tree/accesskit
- paulryanrogers 4y agoReact components built as div soup may actually be worse for accessibility than thoughtfully written no-JS HTML.
- wonnage 4y agoThis statement is practically a tautology
- andrewingram 4y agoAnd no-JS HTML built as div soup is likely worse for accessibility than thoughtfully written React. So React itself has no bearing on it. My take is that it's the growing complexity of web development (yes, React has some responsibility here), combined with the constant influx of new developers, that's largely to blame for any overall proportional loss in the practice of accessible markup.
- ksbrooksjr 4y agoI agree. Another thing to consider is that React makes it frictionless to import custom components, instead of attempting to re-write common UI patterns from scratch. If a React dev leans on an accessible UI framework like Chakra, or Headless UI, or React-Aria, they're probably better off from an accessibility perspective than a dev that tries to implement WAI guidelines from scratch.
- saulrh 4y agoAnd? The point of the parent was that either of those are better than native - doesn't matter how much div soup you have, at least the information exists, unlike the bucket of raw pixels that're all you get from native UIs sometimes.
- paulryanrogers 4y agoDesktop UI frameworks are a bit of a mess. Though truly OS native should be the most accessible of all.