5 ms·

Accessibility will be absolutely destroyed though

xpl 3y ago
I am pretty sure in the end accessibility will more likely be solved by some smart LLMs (with vision) interpreting arbitrary web pages on the user side, rather than by web developers coding it by hand. Because the latter obviously doesn't universally work. I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Think "Reader Mode" on steroids (that could transform arbitrary GUIs, not just blog posts).
- interstice 3y ago
  Interesting idea, and I’d think mostly only limited by cost/speed per token currently
- edent 3y ago
  In the end? Maybe. What about the people who can't use the web now?
- dartos 3y ago
  > I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Sometimes designs you don’t like are intentional.
  - btown 3y ago
    As much as I work painstakingly to implement highly intentional design systems… the browser should be your “user agent.” If it can agentically interpret semi-structured data to help you, it’s entirely the user’s right to have the browser do that for them.
    - DaiPlusPlus 3y ago
      Except Chrome doesn’t support user-stylesheets - which is an outrage (even Internet Explorer supported them). I shouldn’t need to author my own Chrome extension just to set a minimum font-size on pages or disable fixed background images over remote-desktop.
      - btown 3y ago
        Stylus is quite effective for this! https://chrome.google.com/webstore/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
      - kevindamm 3y ago
        Add your styles to Custom.css in the "User StyleSheets" folder of your profile path. No extension authoring needed.
        DaiPlusPlus 3y ago
        This doesn't seem to be documented anywhere - all of the mentions I find about this date from around 2013-ish. There's nothing about it in Chrome's help site either: https://support.google.com/chrome/search?q=user+stylesheet&from_promoted_search=true https://support.google.com/chrome/search?q=user+stylesheet&f... https://support.google.com/chrome/search?q=Custom.css https://support.google.com/chrome/search?q=Custom.css
        kevindamm 3y ago
        hmm, when I get a chance I'll check that it still works, it's not something I still use and you're right that it's not documented
  - rimunroe 3y ago
    I’m sure they are, but that doesn’t mean they’re good or will work well for me
dartos 3y ago
Not if you are good with ur aria tags.
- janosdebugs 3y ago
  That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.
  - egeozcan 3y ago
    Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder. I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way. I have many stories like this. I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things. When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
- yreg 3y ago
  That's not true. Aria isn't a replacement for proper markup. Accessibility software is rather brittle even when you do everything right. It's a bad idea to push it.
  - nsonha 3y ago
    Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.
bazoom42 3y ago
A custom name like <whatever> is not any worse than <span> - both are semantically neutral.

xpl 3y ago

I am pretty sure in the end accessibility will more likely be solved by some smart LLMs (with vision) interpreting arbitrary web pages on the user side, rather than by web developers coding it by hand. Because the latter obviously doesn't universally work. I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Think "Reader Mode" on steroids (that could transform arbitrary GUIs, not just blog posts).

interstice 3y ago
Interesting idea, and I’d think mostly only limited by cost/speed per token currently
edent 3y ago
In the end? Maybe. What about the people who can't use the web now?
dartos 3y ago
> I would pay money for a browser plugin that restyles every web page to a single readable/accessible design that I like. Sometimes designs you don’t like are intentional.
- btown 3y ago
  As much as I work painstakingly to implement highly intentional design systems… the browser should be your “user agent.” If it can agentically interpret semi-structured data to help you, it’s entirely the user’s right to have the browser do that for them.
  - DaiPlusPlus 3y ago
    Except Chrome doesn’t support user-stylesheets - which is an outrage (even Internet Explorer supported them). I shouldn’t need to author my own Chrome extension just to set a minimum font-size on pages or disable fixed background images over remote-desktop.
    - btown 3y ago
      Stylus is quite effective for this! https://chrome.google.com/webstore/detail/stylus/clngdbkpkpeebahjckkjfobafhncgmne https://chrome.google.com/webstore/detail/stylus/clngdbkpkpe...
    - kevindamm 3y ago
      Add your styles to Custom.css in the "User StyleSheets" folder of your profile path. No extension authoring needed.
      - DaiPlusPlus 3y ago
        This doesn't seem to be documented anywhere - all of the mentions I find about this date from around 2013-ish. There's nothing about it in Chrome's help site either: https://support.google.com/chrome/search?q=user+stylesheet&from_promoted_search=true https://support.google.com/chrome/search?q=user+stylesheet&f... https://support.google.com/chrome/search?q=Custom.css https://support.google.com/chrome/search?q=Custom.css
        kevindamm 3y ago
        hmm, when I get a chance I'll check that it still works, it's not something I still use and you're right that it's not documented
- rimunroe 3y ago
  I’m sure they are, but that doesn’t mean they’re good or will work well for me

dartos 3y ago

Not if you are good with ur aria tags.

janosdebugs 3y ago
That's althe funny bit, despite aria, I found in testing that some tags still behave differently with screen readers.
- egeozcan 3y ago
  Just my personal experience: If anyone remembers how hard it was to make things render consistently across IE and Netscape, the current situation with different screen readers is 1000x harder. I mainly test with NVDA on the latest Firefox ESR on Windows 10. Something always breaks if I upgrade any part of this chain in my testing VM. Few months ago I spent many days to make abbreviations in a table header to be read correctly. I tried the abbr tag, abbr attribute, aria-label and many other possibilities and found a super hacky solution that involves hiding the expanded form with some css while exposing it to the screen reader. Then sometime after that I updated the Firefox. At the same day a colleague questioned why we needed all these hacks, and I wanted to show her how broken it was without my hack, but voila it had started working with the non-hacky, semantic way. I have many stories like this. I also do test with other configurations but just before releasing. VoiceOver (mac) is 80% there. JAWS Inspect is giving some colleagues headaches. None work 100% without breaking others, so the most popular stack decides how we implement things. When I saw this post, I thought perhaps doing everything with spans and adding necessary attributes like role would be easier. Well nobody is passing something like that through a code review :)
yreg 3y ago
That's not true. Aria isn't a replacement for proper markup. Accessibility software is rather brittle even when you do everything right. It's a bad idea to push it.
- nsonha 3y ago
  Aria should be the source of truth, the list of things is much simpler and straight forward than html tags. They ARE made for accessibility and accessibility only, unlike html which at worst treat accessibility as an after thought and at best just another overloaded function of the mark up.

bazoom42 3y ago

A custom name like <whatever> is not any worse than <span> - both are semantically neutral.