Well, see, you're on to something: these tools exist as a litigation defense layer: large enough targets sometimes get ADA lawsuit threats. They frequently come with an offer to settle. When you use something like Accessibe, you provide enough of a plausible effort that it's not worth it for the litigious sort to waste their time with you, so they move to other lower hanging fruit.
None of this, you'll note, is particularly concerned with how the tool _actually_ impacts a11y. But, as you state, it's the lazy solution.
The ADA lawsuit trolls who are quick to settle for money tend to go after smaller businesses presumably because they lack the resources to fight in court, to actually fix the problems, and because there are a lot more of them than large businesses.
As a descendant of a totally blind man, but with like 20/12 vision myself, I just have to agree. Dude eyes are the ultimate threat detector, they're essential, and there's so many people trying to take advantage of vision impairment. They need it to be perfect stereotypical blindness to give a single unit of fuck about the problem, no compensating for limitations, all or nothing. Never look from another point of view. Plus all the fake-blind beggars taking advantage of the sympathy that ought to be reserved for the legitimate blind or vision-impaired, of which there are enough as it is.
Oh but you know how I help my vision when it starts declining now and then? Eat fish oil, very pure no mercury, eat it, six softgels a day and your vision will improve. Eyes are almost pure omega-3 omega-6 and omega-9 fats, in the lens and retina. Declining vision is basically due to your body rearranging its unsaturated fat reserves, with which it is endowed at birth and never gets more of. Some people their ears start to go, others their mind start to go (and that's why I was prescribed fish oil by a psychiatrist, but like one a day get real doctors need to up the dose), other people their joints or their heart. You can't just eat fish, the mercury completely undoes the effect. It's not found in nature. Only in labs. It's the fat endowment.
And that's the framework for compensating for blindness: not being blind in the first place. Undoing it. Dude you can eat 15 softgels a day.
Mmm...it's not that fast...like three weeks? And it is already recommended for that, my difference of opinion is in the quantity. It came down to reading an article about a man with heavy no talking no walking brain damage. He got 15 a day and recovered in six months.
My favorite is UP, Ultra Pure brand, but I can't find it outside Chile. In US, Nature's Bounty, just anything with very low amounts of mercury cadmium and pcb's.
UP, Ultra Pure, couldn't find it in the States, they sell it in Chile, in Liga Chilena Contra la Epilepsia, that place has the best prices. It's clearly the best, comes from the clean waters of the South Pacific, it's palpably purer.
I've seen capsule sizes 1200 mg, 1600 mg, I think 1800 mg. Some were small. Ignore the difference, take a lot, take the big softgels like they were small softgels. Don't take it, eat it.
Increasingly I think the screenreader/ARIA proposition of navigating a (linearized ordering of) elements on a 2D page is fundamentally limiting for blind users. The web needs a more robust model of application state from which text, audio, and GUI representations can be derived. Our applications clearly structure "objects" and their "methods" under the hood, and it should be possible to present these more directly to users in whatever format makes sense to them.
Maybe I don't get what you want to express, but screen readers allow for alternative presentations of an HTML document, allowing for alternative modes of content discovery, e.g. hierarchical outlines of headlines and "landmarks".
Several ARIA attributes further allow for communicating the current application state, e.g. whether content has changed (aria-live), a button is in a pressed state (aria-pressed), or a menu is opened (aria-expanded).
It has to be linearized because hearing, and time itself, are one-dimensional.
Screen readers can represent nesting of content, going into one element and coming back out, Apple's VoiceOver in particular uses this concept. It may be conceptually helpful in some instances or to some people but often it just makes things more cumbersome to navigate.
When I worked at the university, doing their websites, I simply could not get accessibility on anyone's radar: my boss, the people in the power structure nearby, the awful design people who saw the Web as a means to deliver photography and, if forced, text in a brochure format.
I had my own tools -- making sure the XHTML and CSS were valid, testing on multiple browsers, testing on lynx, a separate PC with jankety mouse settings to make it hard to click and a few sets of glasses to distort my vision, etc. Accessibility has to be a first class citizen when you make that template, it cannot be bolted on later. And it means being rigorous: fill out that alt text, test that tab order. I had no budget, just raw stubbornness and a willingness to be the bad guy.
It was continually infuriating that nobody cared about people with low vision, or crap bandwidth, or colorblindness, or motor tremor, because, barring an early death or really great health, we're all liable to enter one or more of these groups with time.
The last, sad argument I had, which worked and was shameful, is that good accessibility almost automatically makes your SEO better. It is both true and mildly upsetting to have to resort to, I felt like I was saying "... also, orphans are more gamey than other kinds of meat."
I don't think you can Javascript your way out of these very real problems. What is needed is an Accessibility Czar for your web properties, who can veto anything, who can pull off their shoe and pound it off the table and force someone on the Design Team to wear a little duncecap as they read out an article on Target getting mauled by the ADA for their screwups.
I think of better accessibility as being better usability, and thus 'accessibility measures' as 'good ideas' per se for any infrastructure that cares about its users -- of course, the problem is that many organizations do not.
I actually randomly get reminded of this now and then, when I:
- open a door with an elbow instead of greasy or occupied hands
- tab through a UI or use alt key shortcuts to quickly perform repetitive tasks not worth automating
- take carts, bicycles, and other heavy objects up accessible ramps, kerb ramps, or mandatory lifts
- read alt tags of images that fail to load or that the file host has lost
- search in or read the captions/subtitles of media that doesn't get to the point
- read captions when I can't play audio
- machine-translate autogenerated captions from unknown languages
Not to mention all that gets taken for granted that wouldn't exist had it not been required.
In the disability spectrum chart linked there, the figure with a sword and round shield illustrating the 'Heavy Accent => Speech x Situational' case is brilliant; going far backwards in time guarantees linguistic distance from any viewer.
What you're describing is named the "curb cut effect" [0].
> The curb cut effect is the phenomenon of disability-friendly features being used and appreciated by a larger group than the people they were designed for. For example, many hearing people use closed captioning.
I'm really sorry you go through this too. I face a similar uphill battle at work and it's like shouting into a void (or should I say, avoidance...)
What boggles me is that we have a dedicated UX team who seem not to care one whit for bandwidth and accessibility, just imprinting their 'vision' across the org through design systems. Questions around these topics are handwaved away. But speed and accessibility _are_ part of user experience, it's in the name sir!
Bless you for doing that. I have eye isses and every so often I suggest to devs that they put a thin layer of vaseline on their glasses just to see what a lot of older people do.
I appreciatie your engagement. But as an engineer, be aware that many of your colleagues mostly want to please their boss, and have a hard time imagining any disability. If accessibility is not on the organization’s radar, the best strategy is suggesting techniques and requirements that benefit disabled AND some other interest, such as SEO, scaling the site to mobile screens, (automatic) testing, config options that benefit multiple user groups. This will ensure that your colleagues and management have a stake in building and maintaining the accessibility features.
Lastly, I found the following video enlightening:
“Accessibility [for game developers] on a shoestring” GDC 2021
https://youtu.be/PiCsvZZh5-k
I'll bet your university has a team of lawyers who would be more than happy to talk to your boss on your behalf about the ADA. Just send them a message and they will deal with it. If they don't keep your copy of the message handy so you can bring it to court with you when the university is sued - you can make out very well for keeping evidence of illegal conduct.
To receive funding from some government bodies in the US there is an accessibility requirement the funds recipient must attest. Of course they could attest to anything if they know the party they're making these statements has no mechanism to ensure the statements are valid.
Our best results in meeting accessibility has been to incorporate them into design standards guide and in a brand's style guide, right next to approved fonts, colors, logos, etc. Teams never think about asking for accessibility standards but always make sure to references the other guides.
I would recommend that everyone go check out Sian Bahram’s 2016 talk on computing while blind. At around 6:30 he specifically addresses how inaccessible HN is to a visually impaired user: https://www.youtube.com/watch?v=G1r55efei5c
Wow. I don't know anything about screen readers or how blind people use the web, but I'm surprised that a strictly text website like HN would be inaccessible to blind people.
Sina is great, it's a shame the device output is so much louder than his microphone in the video.
I didn't hear him mention the lack of skip links on HN's home page (skip links are more for sighted keyboard users than blind screen reader users like him), I did hear him mention that the stories on the home page are not headings. Yes, a screen reader can navigate link to link but there are ~7 non-story links between each story link so being able to navigate from story to story as headings would be really helpful and semantically accurate.
One idle idea I had at some a11y conference was this: as a person doing a lot of CMS customization, almost all the software I write is an accommodation to all kinds of people.
Specifically, I personally can just write content straight to a database with my DB client. I can write nice, valid HTML. I can crop photos and output them just fine with various CLI and GUI applications.
The people I work with cannot.
So I write bits of code so that they can edit headlines and page titles without having to open a plain text editor. I create extensions so that the graphic element they want to include is done in a way that doesn't break the page markup. I write code so they can use the mouse to drag photos to where they need to place them in the articles they want to publish.
And people have accommodated my own needs: I really don't understand how my SSH keys work, just that they do work. I don't know how to write an SQL client, but someone wrote one I can use. Etc, etc.
The idea that as folks who are making things, a large portion of what we do is enabling people to do things they couldn't otherwise do makes me feel a great deal of solidarity with everyone who currently needs more accommodations than I do.
Pragmatically, if we live long enough we will all eventually have a hard time seeing the screen, clicking with a mouse, understanding new UI modalities, etc.
I find that fact quite motivating it means I am not just trying to be kind to other folks: working to make a11y a must-have is an action in solidarity with our own interests and not just a thing we might do for other people.
Thanks for sharing this, it's a really good way of framing the issue in a way that others will find relatable. I am going to use this at my workplace, and hopefully it will, at the very least, plant the seeds in their minds.
Are there any positive examples of popular websites which are also well designed in terms of accessibility? I don't think that accessibility and modern design have to be at odds, but it would be interesting to see how this is achieved in practise.
gov.uk is the quintessential example, but I'm not sure it meets the bar for "popular". Sure, lots of people use it, but that's because they have to.
I don't rely on accessibility tools myself(outside of Vimium for keyboard navigation) but I get the impression that Twitter is pretty well done. In between adding support for alt tags on user uploaded content, actually implementing a custom focus language, and bespoke screen reader labelling they seem to at least care about it.
I’ve worked at both the bbc and ft.com and we put quite a bit of effort into accessibility. I think we were pretty successful but others are probably on a better position to judge
I've been thinking about this lately for a SDL project I'm working on. So far there doesn't seem to be any guide to doing accessibility from scratch. My plan is to test with the Orca screen reader from Gnome.
You just can't expect a script to make a website accessible. Accessibility cannot be fully automated. Sure there are tools that can highlight some issues, and provide guided review to help find others, but there's no panacea.
Instead, start with a UI library that already applies accessibility best practices, such as Material UI [0], then follow the guidance provided for each component (a library can't do everything for you, despite what many claim), as well as applying accessibility best practices to the site as a whole. Only then apply automated review, and manual review by accessibility experts, fixing issues raised at each stage.
That’s great until design decides that modals shouldn’t close with the escape key and users should be forced to scroll a text field and click a toggle to navigate away.
Then some data elsewhere on the page animates to a new value, and the user should be notified of this data immediately.
Designers don’t like using prebuilt components. I haven’t found one yet that can live with constraints.
It sounds like design needs to be educated on accessibility. That said, all this and more is possible with Material UI. It's designed for flexibility and customizability in both functionality and appearance.
That doesn't make it okay to break accessibility though.
Until you need to theme some tabs because design must align the text and icons -just so- and quickly find that not everything in material is themable. Some things are missing.
So you style deep dom elements that break when you upgrade material, if you ever do, because upgrading is now too expensive with the Frankenstein you’ve tried to jam into material’s default styles.
I’ve worked with many, many designers. None of them have ever liked working with constraints. Even getting a single designer to commit to a color palette is pulling teeth.
Karl Groves, the "Web Accessibility Viking" wrote a great piece* naming several "accessibility-overlay" services that make matters much worse... As a result he is getting sued into oblivion by said company...
I wouldn't consider myself an accessibility specialist, but I know a thing or two about it, specifically on how to deploy it strategically in a large organization (Fortune 500).
I'd say the lack of accessibility is not really due to indifference, much more likely it is plain ignorance. Most people know close to nothing about accessibility, worse, don't even know that they need to know.
There's also a technical perspective. Web tech in general is very low level primitives that you stitch together, not really a coherent higher order UI stack. This means that for any given goal, there's a million ways to do it. There's a stunning lack of UI elements but even simple elements that do exist do not truly enforce accessibility.
For example, there's no such thing as a tab component, so people build their own. It's relatively difficult to make it fully accessible. And that assumes you'd even know about accessibility.
Take a simpler element, the img element. I might not know that there is such a thing as an "alt" tag. I'm supposed to know but nothing enforces this knowledge, there's no standard education in web dev. Even if I do know about the alt tag, I might ignore it, as excuse I'll use "other priorities". Or I do use it, but incorrectly, which happens more often than not.
My point is that all of this is almost entirely dependent on personal knowledge and discipline, which is a recipe for disaster at web scale. We need better foundations.
That said, there's reasons to be hopeful. It's definitely getting more attention nowadays and the tooling ecosystem is rapidly improving.
Accessible pages, like no-javascript pages, should be dedicated, mixing accessibility with general UX is simply not working, this adds too many constraints on design that companies don't want to sacrifice. Browsers should allow users to request various levels of accessibility thru headers.
51 comments
[ 5.9 ms ] story [ 105 ms ] threadNone of this, you'll note, is particularly concerned with how the tool _actually_ impacts a11y. But, as you state, it's the lazy solution.
https://adrianroselli.com/2020/06/accessibe-will-get-you-sue...
The ADA lawsuit trolls who are quick to settle for money tend to go after smaller businesses presumably because they lack the resources to fight in court, to actually fix the problems, and because there are a lot more of them than large businesses.
https://web.archive.org/web/20220717011807/https://www.nytim...
Oh but you know how I help my vision when it starts declining now and then? Eat fish oil, very pure no mercury, eat it, six softgels a day and your vision will improve. Eyes are almost pure omega-3 omega-6 and omega-9 fats, in the lens and retina. Declining vision is basically due to your body rearranging its unsaturated fat reserves, with which it is endowed at birth and never gets more of. Some people their ears start to go, others their mind start to go (and that's why I was prescribed fish oil by a psychiatrist, but like one a day get real doctors need to up the dose), other people their joints or their heart. You can't just eat fish, the mercury completely undoes the effect. It's not found in nature. Only in labs. It's the fat endowment.
And that's the framework for compensating for blindness: not being blind in the first place. Undoing it. Dude you can eat 15 softgels a day.
My favorite is UP, Ultra Pure brand, but I can't find it outside Chile. In US, Nature's Bounty, just anything with very low amounts of mercury cadmium and pcb's.
So. Do you have a brand of fish oil we all can look into and research?
Also, there's this 2018 NIH study that says fish oil is no better than a placebo for dry eyes: https://www.nih.gov/news-events/news-releases/omega-3s-fish-...
Several ARIA attributes further allow for communicating the current application state, e.g. whether content has changed (aria-live), a button is in a pressed state (aria-pressed), or a menu is opened (aria-expanded).
Screen readers can represent nesting of content, going into one element and coming back out, Apple's VoiceOver in particular uses this concept. It may be conceptually helpful in some instances or to some people but often it just makes things more cumbersome to navigate.
In an ideal world, we could have entirely different clients that focus on audio-touch interfaces like a some sort of keyboard driven Alexa skill.
When I worked at the university, doing their websites, I simply could not get accessibility on anyone's radar: my boss, the people in the power structure nearby, the awful design people who saw the Web as a means to deliver photography and, if forced, text in a brochure format.
I had my own tools -- making sure the XHTML and CSS were valid, testing on multiple browsers, testing on lynx, a separate PC with jankety mouse settings to make it hard to click and a few sets of glasses to distort my vision, etc. Accessibility has to be a first class citizen when you make that template, it cannot be bolted on later. And it means being rigorous: fill out that alt text, test that tab order. I had no budget, just raw stubbornness and a willingness to be the bad guy.
It was continually infuriating that nobody cared about people with low vision, or crap bandwidth, or colorblindness, or motor tremor, because, barring an early death or really great health, we're all liable to enter one or more of these groups with time.
The last, sad argument I had, which worked and was shameful, is that good accessibility almost automatically makes your SEO better. It is both true and mildly upsetting to have to resort to, I felt like I was saying "... also, orphans are more gamey than other kinds of meat."
I don't think you can Javascript your way out of these very real problems. What is needed is an Accessibility Czar for your web properties, who can veto anything, who can pull off their shoe and pound it off the table and force someone on the Design Team to wear a little duncecap as they read out an article on Target getting mauled by the ADA for their screwups.
I actually randomly get reminded of this now and then, when I:
- open a door with an elbow instead of greasy or occupied hands
- tab through a UI or use alt key shortcuts to quickly perform repetitive tasks not worth automating
- take carts, bicycles, and other heavy objects up accessible ramps, kerb ramps, or mandatory lifts
- read alt tags of images that fail to load or that the file host has lost
- search in or read the captions/subtitles of media that doesn't get to the point
- read captions when I can't play audio
- machine-translate autogenerated captions from unknown languages
Not to mention all that gets taken for granted that wouldn't exist had it not been required.
Edit:
Found a submission about just this while searching for your past rants:) https://news.ycombinator.com/item?id=30062178
In the disability spectrum chart linked there, the figure with a sword and round shield illustrating the 'Heavy Accent => Speech x Situational' case is brilliant; going far backwards in time guarantees linguistic distance from any viewer.
> The curb cut effect is the phenomenon of disability-friendly features being used and appreciated by a larger group than the people they were designed for. For example, many hearing people use closed captioning.
[0] https://en.wikipedia.org/wiki/Curb_cut_effect
What boggles me is that we have a dedicated UX team who seem not to care one whit for bandwidth and accessibility, just imprinting their 'vision' across the org through design systems. Questions around these topics are handwaved away. But speed and accessibility _are_ part of user experience, it's in the name sir!
That's why each of us should routinely be doing a few hours of customer support for the thing you build. Very humbling and educational.
Bless you for doing that. I have eye isses and every so often I suggest to devs that they put a thin layer of vaseline on their glasses just to see what a lot of older people do.
Lastly, I found the following video enlightening: “Accessibility [for game developers] on a shoestring” GDC 2021 https://youtu.be/PiCsvZZh5-k
This would be awesome swag at conferences that are frequented by frontend engineers.
Our best results in meeting accessibility has been to incorporate them into design standards guide and in a brand's style guide, right next to approved fonts, colors, logos, etc. Teams never think about asking for accessibility standards but always make sure to references the other guides.
Or do you mean on the front page?
I didn't hear him mention the lack of skip links on HN's home page (skip links are more for sighted keyboard users than blind screen reader users like him), I did hear him mention that the stories on the home page are not headings. Yes, a screen reader can navigate link to link but there are ~7 non-story links between each story link so being able to navigate from story to story as headings would be really helpful and semantically accurate.
Specifically, I personally can just write content straight to a database with my DB client. I can write nice, valid HTML. I can crop photos and output them just fine with various CLI and GUI applications.
The people I work with cannot.
So I write bits of code so that they can edit headlines and page titles without having to open a plain text editor. I create extensions so that the graphic element they want to include is done in a way that doesn't break the page markup. I write code so they can use the mouse to drag photos to where they need to place them in the articles they want to publish.
And people have accommodated my own needs: I really don't understand how my SSH keys work, just that they do work. I don't know how to write an SQL client, but someone wrote one I can use. Etc, etc.
The idea that as folks who are making things, a large portion of what we do is enabling people to do things they couldn't otherwise do makes me feel a great deal of solidarity with everyone who currently needs more accommodations than I do.
Pragmatically, if we live long enough we will all eventually have a hard time seeing the screen, clicking with a mouse, understanding new UI modalities, etc.
I find that fact quite motivating it means I am not just trying to be kind to other folks: working to make a11y a must-have is an action in solidarity with our own interests and not just a thing we might do for other people.
I don't rely on accessibility tools myself(outside of Vimium for keyboard navigation) but I get the impression that Twitter is pretty well done. In between adding support for alt tags on user uploaded content, actually implementing a custom focus language, and bespoke screen reader labelling they seem to at least care about it.
Well, that’s probably just as much up in the air.
Instead, start with a UI library that already applies accessibility best practices, such as Material UI [0], then follow the guidance provided for each component (a library can't do everything for you, despite what many claim), as well as applying accessibility best practices to the site as a whole. Only then apply automated review, and manual review by accessibility experts, fixing issues raised at each stage.
Disclosure – I contribute to Material UI.
[0] https://mui.com/material-ui/react-text-field/#accessibility
Then some data elsewhere on the page animates to a new value, and the user should be notified of this data immediately.
Designers don’t like using prebuilt components. I haven’t found one yet that can live with constraints.
That doesn't make it okay to break accessibility though.
So you style deep dom elements that break when you upgrade material, if you ever do, because upgrading is now too expensive with the Frankenstein you’ve tried to jam into material’s default styles.
I’ve worked with many, many designers. None of them have ever liked working with constraints. Even getting a single designer to commit to a color palette is pulling teeth.
*People with disabilities hate overlays yet an overlay company is suing its critic, now snubbed from the internet (article scrubbed from his site). https://karlgroves.com/people-with-disabilities-hate-overlay...
I'd say the lack of accessibility is not really due to indifference, much more likely it is plain ignorance. Most people know close to nothing about accessibility, worse, don't even know that they need to know.
There's also a technical perspective. Web tech in general is very low level primitives that you stitch together, not really a coherent higher order UI stack. This means that for any given goal, there's a million ways to do it. There's a stunning lack of UI elements but even simple elements that do exist do not truly enforce accessibility.
For example, there's no such thing as a tab component, so people build their own. It's relatively difficult to make it fully accessible. And that assumes you'd even know about accessibility.
Take a simpler element, the img element. I might not know that there is such a thing as an "alt" tag. I'm supposed to know but nothing enforces this knowledge, there's no standard education in web dev. Even if I do know about the alt tag, I might ignore it, as excuse I'll use "other priorities". Or I do use it, but incorrectly, which happens more often than not.
My point is that all of this is almost entirely dependent on personal knowledge and discipline, which is a recipe for disaster at web scale. We need better foundations.
That said, there's reasons to be hopeful. It's definitely getting more attention nowadays and the tooling ecosystem is rapidly improving.