4 ms·

A11y seems to be caught between "those members of the population who benefit from it, deserve to" and "those members of the population are a tiny portion and th

A11y seems to be caught between "those members of the population who benefit from it, deserve to" and "those members of the population are a tiny portion and the business value is minor vs. the cost". I'd like to hear thoughts from those who have successfully argued against the latter. There's obviously parallels with physical accommodations like ramps and lifts, which it would seem daft to forego in 2024, yet software development prioritisation seems to only care about Business Value. (Assume I'm talking about for profit software here)

amarshall 2y ago
Plenty of places would likely not have put in ramps and lifts if the law didn’t require them to.
wging 2y ago
My impression is that there are (possibly underenforced) US laws that mandate a certain amount of accessibility - the ADA and possibly others. (I'm 100% not a lawyer, this is not legal advice.) At a previous job, that was the justification for a mandate to make sure our website and mobile app was accessible prior to its general availability. (It's also the right thing, as we knew, but the existence of a legal requirement tends to give doing the right thing a lot more priority in a team's backlog. So there's at least one case of the law working as designed.) See also https://en.wikipedia.org/wiki/Americans_with_Disabilities_Act_of_1990#Web_Content_Accessibility_Guidelines,_2019 https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac... -- the experience I'm talking about was prior to the mentioned 9th Circuit ruling or the Supreme Court's 2019 declining of the appeal, but the laws were on the books already. I don't remember exactly whether the Target case is what was mentioned as a motivating factor to us, but it might have been: <https://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corp. https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...> (I say 'possibly underenforced' because I don't really know enough about the accessibility landscape, but I somehow doubt that every customer unlawfully prevented from accessing services that the ADA covers actually sues...)
- dylan604 2y ago
  Part of ADA compliance comes with applying for a Certificate of Occupancy for your space. If things do not meet minimum satisfaction, they will not issue the CO. If your space is part of a larger building, it'll probably be something to work out with the building itself if there are issues. So comparing it to ramps/rails/parking spaces for ADA is harder as most construction has had that built into it for a long time now, and existing spaces have most likely been retrofitted. Websites just don't have that level of red tape to launch. People do not need a government issued certificate of minimum level of compliance to launch. There are way too many sites for pretty much any government to monitor for ADA compliance. There's probably a way to report issues, but who has the time to look up where to do that? Some part of my foggy memory also thinks there's a caveat for the size of the company running a website about how strict compliance needs to be, but that might getting confused with cookie banners???
TheAceOfHearts 2y ago
a11y education was just absolutely abysmal when I started learning web development. Even if you had good intentions, figuring out how to make something accessible when you were building out new widgets required a lot of research. I think documentation has gotten a bit better since then, but it still relies on having an engineer that cares enough to bother learning about the topic in the first place. If you compare Chrome Dev Tools now to what was available 10 years ago, the difference in capabilities was stark. My memory is fuzzy, but I don't think it had support for anything related to accessibility, but over the years they kept adding new features to make it easier to build accessible websites. I think it's an education gap which can be closed with better tools and documentation.
- PhilipRoman 2y ago
  The thing is, normal html as originally written by humans is already very accessible by default. Only when you cram a bunch of unnecessary content, JS frameworks and reimplement browser elements in software it becomes a problem.
vector_spaces 2y ago
#1. I think when people hear discussion about accessibility, there is an assumption that the only people who benefit are folks who are blind, deaf, or with severe physical impairments requiring a wheelchair. In fact, web accessibility best-practices also aim to reduce barriers for folks who have e.g. ADHD, autism, dyscalculia, trauma disorders, poor network connections, cheap/low-grade devices, difficulties with mobility and motor control, stroke, color blindness, memory impairments, among many, many others -- ultimately lots, and lots, and lots of people. Also, web accessibility standards cover not only physical and intellectual/cognitive disabilities but also socio-economic and situational impairments (e.g. you're situationally one-handed because you're carrying a baby). On top of that, it turns out that just as ramps and lifts are quite helpful for nondisabled (situationally or otherwise) folks in many circumstances, so too are websites that don't violate web and accessibility standards by hijacking browser functionality and behave predictably. #2. The idea that folks have about how "those members of the population are a tiny portion and the business value is minor" is very strange and patently false: the vast majority of people on planet earth will experience disability at some point in their lives. One in ten Americans has a disability, that rises sharply with age to nearly 1 in 2 for older Americans. These aren't difficult stats to find sources for -- so I think this particular argument constitutes a certain level of willful ignorance underlying much of the difficulty disability advocates face.
- rileymat2 2y ago
  With respect to your second point, it is grouping a lot of different disabilities together instead of looking at the addition of one affordance for a particular disability.
Symbiote 2y ago
> A11y This word is inaccessible to those unfamiliar with the abbreviation, such as many non-native speakers who would have difficulty guessing. Just write "accessibility".
moozilla 2y ago
One point I haven't seen mentioned yet is that a11y provides obvious business value in that it forces devs to write better and more testable code. I first noticed this when using react-testing-library [1], when refactoring my code to be more easily testable became equivalent to adding a11y features. Example from a project I worked on: I needed to test that when a button is clicked that the app showed a spinner when loading and then the content when the API call completed successfully. The spinner component was just an SVG with no obvious way to select it without adding a test-id, so instead I refactored the app to use an aria-busy attribute [2] in the container where the content is loading. The test then becomes something like this: test('shows spinner while loading and content after API call', async () => { render(<Example />); userEvent.click(screen.getByRole('button', { name: /load content/i })); expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'true'); await waitFor(() => { expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'false'); expect(screen.getByText(/content loaded/i)).toBeInTheDocument(); }); }); [1] https://testing-library.com/docs/queries/about#priority https://testing-library.com/docs/queries/about#priority [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-busy https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...

amarshall 2y ago

Plenty of places would likely not have put in ramps and lifts if the law didn’t require them to.

wging 2y ago

My impression is that there are (possibly underenforced) US laws that mandate a certain amount of accessibility - the ADA and possibly others. (I'm 100% not a lawyer, this is not legal advice.) At a previous job, that was the justification for a mandate to make sure our website and mobile app was accessible prior to its general availability. (It's also the right thing, as we knew, but the existence of a legal requirement tends to give doing the right thing a lot more priority in a team's backlog. So there's at least one case of the law working as designed.) See also https://en.wikipedia.org/wiki/Americans_with_Disabilities_Act_of_1990#Web_Content_Accessibility_Guidelines,_2019 https://en.wikipedia.org/wiki/Americans_with_Disabilities_Ac... -- the experience I'm talking about was prior to the mentioned 9th Circuit ruling or the Supreme Court's 2019 declining of the appeal, but the laws were on the books already. I don't remember exactly whether the Target case is what was mentioned as a motivating factor to us, but it might have been: <https://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corp. https://en.wikipedia.org/wiki/National_Federation_of_the_Bli...> (I say 'possibly underenforced' because I don't really know enough about the accessibility landscape, but I somehow doubt that every customer unlawfully prevented from accessing services that the ADA covers actually sues...)

dylan604 2y ago
Part of ADA compliance comes with applying for a Certificate of Occupancy for your space. If things do not meet minimum satisfaction, they will not issue the CO. If your space is part of a larger building, it'll probably be something to work out with the building itself if there are issues. So comparing it to ramps/rails/parking spaces for ADA is harder as most construction has had that built into it for a long time now, and existing spaces have most likely been retrofitted. Websites just don't have that level of red tape to launch. People do not need a government issued certificate of minimum level of compliance to launch. There are way too many sites for pretty much any government to monitor for ADA compliance. There's probably a way to report issues, but who has the time to look up where to do that? Some part of my foggy memory also thinks there's a caveat for the size of the company running a website about how strict compliance needs to be, but that might getting confused with cookie banners???

TheAceOfHearts 2y ago

a11y education was just absolutely abysmal when I started learning web development. Even if you had good intentions, figuring out how to make something accessible when you were building out new widgets required a lot of research. I think documentation has gotten a bit better since then, but it still relies on having an engineer that cares enough to bother learning about the topic in the first place. If you compare Chrome Dev Tools now to what was available 10 years ago, the difference in capabilities was stark. My memory is fuzzy, but I don't think it had support for anything related to accessibility, but over the years they kept adding new features to make it easier to build accessible websites. I think it's an education gap which can be closed with better tools and documentation.

PhilipRoman 2y ago
The thing is, normal html as originally written by humans is already very accessible by default. Only when you cram a bunch of unnecessary content, JS frameworks and reimplement browser elements in software it becomes a problem.

vector_spaces 2y ago

#1. I think when people hear discussion about accessibility, there is an assumption that the only people who benefit are folks who are blind, deaf, or with severe physical impairments requiring a wheelchair. In fact, web accessibility best-practices also aim to reduce barriers for folks who have e.g. ADHD, autism, dyscalculia, trauma disorders, poor network connections, cheap/low-grade devices, difficulties with mobility and motor control, stroke, color blindness, memory impairments, among many, many others -- ultimately lots, and lots, and lots of people. Also, web accessibility standards cover not only physical and intellectual/cognitive disabilities but also socio-economic and situational impairments (e.g. you're situationally one-handed because you're carrying a baby). On top of that, it turns out that just as ramps and lifts are quite helpful for nondisabled (situationally or otherwise) folks in many circumstances, so too are websites that don't violate web and accessibility standards by hijacking browser functionality and behave predictably. #2. The idea that folks have about how "those members of the population are a tiny portion and the business value is minor" is very strange and patently false: the vast majority of people on planet earth will experience disability at some point in their lives. One in ten Americans has a disability, that rises sharply with age to nearly 1 in 2 for older Americans. These aren't difficult stats to find sources for -- so I think this particular argument constitutes a certain level of willful ignorance underlying much of the difficulty disability advocates face.

rileymat2 2y ago
With respect to your second point, it is grouping a lot of different disabilities together instead of looking at the addition of one affordance for a particular disability.

Symbiote 2y ago

> A11y This word is inaccessible to those unfamiliar with the abbreviation, such as many non-native speakers who would have difficulty guessing. Just write "accessibility".

moozilla 2y ago

One point I haven't seen mentioned yet is that a11y provides obvious business value in that it forces devs to write better and more testable code. I first noticed this when using react-testing-library [1], when refactoring my code to be more easily testable became equivalent to adding a11y features. Example from a project I worked on: I needed to test that when a button is clicked that the app showed a spinner when loading and then the content when the API call completed successfully. The spinner component was just an SVG with no obvious way to select it without adding a test-id, so instead I refactored the app to use an aria-busy attribute [2] in the container where the content is loading. The test then becomes something like this: test('shows spinner while loading and content after API call', async () => { render(<Example />); userEvent.click(screen.getByRole('button', { name: /load content/i })); expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'true'); await waitFor(() => { expect(screen.getByRole('main')).toHaveAttribute('aria-busy', 'false'); expect(screen.getByText(/content loaded/i)).toBeInTheDocument(); }); }); [1] https://testing-library.com/docs/queries/about#priority https://testing-library.com/docs/queries/about#priority [2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Attributes/aria-busy https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...