(Assume I'm talking about for profit software here)
(Assume I'm talking about for profit software here)
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.
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
[2] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...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_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_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...)
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???
This word is inaccessible to those unfamiliar with the abbreviation, such as many non-native speakers who would have difficulty guessing.
Just write "accessibility".
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.