1
0
Fork 0
mirror of https://git.sr.ht/~seirdy/seirdy.one synced 2024-11-15 09:52:10 +00:00
seirdy.one/content/notes/assistive-technology-support-versus-textual-browsers.md
2022-11-06 22:04:08 -07:00

1.2 KiB

title date replyURI replyTitle replyType replyAuthor replyAuthorURI
Assistive technology support versus textual browsers 2022-11-06T22:04:08-08:00 https://mastodon.cisti.org/@GustavinoBevilacqua/109300551030058031 many screen readers for blind people are based on lynx SocialMediaPosting Gustavino Bevilacqua https://mastodon.cisti.org/@GustavinoBevilacqua

This is an idea I've seen repeated before. I need to push back on it.

Assistive technology (AT) interfaces with an operating system's accessibility APIs. A browser converts the Document Object Model (DOM) into an assistive tree, and sends that to the OS accessibility API.

Now, some screen readers actually do hook into the browser; NVDA does this with Firefox and Chromium. But this isn't always the case. ATs need to crawl an accessibility tree for the entire desktop environment, and the browser is one of many windows present. They don't just convert markup to text.

A semantic screen-reader friendly site may look awful in Lynx. A Lynx-friendly site may have terrible semantics and navigate poorly in a screen reader. To work well in both scenarios, deliver content with semantic markup and make non-markup resources optional.