Top accessibility complaints from people with disabilities | Hacker News Reader

Top accessibility complaints from people with disabilities

axesslab.com

279 pointssstriegs132 comments

What bothers me more than people designing inaccessable sites is their excuse of "well, why put extra money and effort into catering to such a small segment of the population?"

Videos released without captions are OK, because "they're free!" Websites without Aria tags are OK, because "screen readers just need to get better." Low contrast fonts are OK, because "my design won't work with different font colors."

Everyone who doesn't die in their prime of life will eventually be disabled in some fashion; but so few people really seem to realize this (or care).

EDIT: Good question - do I practice what I preach? Yes, I do. I'm in an SRE position, and a few of our developers are hard of hearing, so I caption the training videos I make, without asking if they need them. No blind folks, but I make sure to use reasonable styles and page layouts to support fading eyesight. I don't set up Aria tags myself, because I don't have any users who need them at the moment.

None of my external or OS contributions are to UI related projects, so nothing of note there.

Accessibility costs a lot of money and it's a perfectly valid observation that one can skimp on it for profit. You may call it immoral, I call it mathematics.

Except that makes things easier for everyone else too. For example I often can't watch videos at work. If that's the only way to get information about your product or fix to an issues you might as well be speaking Martian in that video I can't use it.

The engines behind Alexa and Google Assistant have decent enough accuracy, I'm not sure why there couldn't be a product to run the audio through those to get subtitles.

When there's not a single audio source for the main speaker, that becomes a problem, but that's the fault of the people recording it for not getting a clean audio source. However, in practice, this is rarely going to be the case for something like a product video because the studio will have recorded it correctly in isolated sound rooms.

We're automatically reverting to "a human should do it" with adding aria tags, video subtitles, and screen readers. That is the problem because developers often have many other things to worry about -- database, security, scalability, maintenance, documentation. Accessibility gets put right beside those and it's no wonder developers don't prioritize it.

It doesn't work well enough. We're no where NEAR it working well enough. People invent new words (product names, technologies), the text isn't synced to the video, there is background noise, the speech-to-text engine doesn't have the context of the video to guess which homophone is correct.

Technology is not the magic bullet to fix everything. We're no where near that place.

In the mean time, I still can't use your site. And neither can people with any number of other issues (medical, environmental, simple bandwidth, etc).

Don't pawn it off on tech, people need to take responsibility for this kind of stuff.

More importantly, accessibility is hard and complicated.

There aren't good tools for collaboratively captioning videos ala a Google Doc. ARIA is a massively complicated spec that is much harder than <font color="red"> tags.

There are simple and easy tools for making inaccessible content (Flash was a big one). It is much, much harder to make accessible content, and it shouldn't be that way.

Financial perspective is an issue but this also.

Its complicated and its not directly related to your core work/competency. One uses a lot of frameworks/tools to build on top of what if they are accessible and you can't build the thing completely on your own? Its quite to get started to be sure which one is just some regulatory checklist and which ones actually matter. I have trying to be knowledgeable on this but compared to normal web development informations are both sparse and harder to grok. And its also much harder to test/validate than just checking if my script/css is working/looking right. I have done very little screenreader tests but it somethings they are terribly good at working through and some things break too easily. It might make perfect sense for an accessibility expert but can be very non-intuitive for a regular developer.

Perfect compliance with Sccessibility can be hard and complicated; but have another look at the original article. The things being asked for are not hard or complicated.

Making no effort just because a perfect effort would be hard comes across as a cop out. Would we accept this so easily if we were discussing testing?

If you can push back on $BOSS, certainly. But, frankly, it's way too easy to make inaccessible content.

It should be impossible to make inaccessible content. We could have browsers and/or compilers that just break the whole page if it isn't accessible.

I dunno, satisfying both "not low contrast" and "not bright colour schemes" together, along with a good design in general, requires a moderate amount of knowledge.

I'm not arguing that it shouldn't be done, but the idea that it's effortless is simply not true.

If this is truly the case then website accessibility will end up going the way of physical disability accommodations -- legally required.

It has in some cases. In the US, The DOT requires it for airline websites.

Ultimately you're mostly talking about the cost of digital typography.

The cost of accessibility depends upon many factors.

If your design starts with accessibility in mind, the costs can be minimal. Keep in mind that the use of small and low contrast elements is a design decision. If the decision is made to use large and high contrast elements from the start, there should be no difference in the development costs. Making it possible to scale pages for pages where things are laid out spatially is far more difficult and incurs much more testing, yet costs can be reduced if the decision is made from the outset. Even the more difficult factors, such as captioning images and videos, can be eased if planning is done ahead.

The problem with arguing that it's 'mathematics' is that there are many variables involved in the equation. If the variables use values for poor planning and design decisions, the result is going to be a much higher cost. If the variables use values for solid planning and design decisions, the difference is going to be much lower. Of course it also depends upon the media being used, so it is very difficult to use that equation to make generalizations for all cases.

"Accessibility costs money" is a popular thing to say, but I'm not convinced that needs to be true. Okay, fine, captioning/transcribing videos I'll give you, but many of the other issues on this page can be addressed for a web page just by not breaking the defaults.

By default, links are underlined. For text content, many major browsers (Firefox and mobile Safari for sure) include a "reader mode" or similar where the user can adjust their own contrast - as long as you don't break your HTML and prevent the reader mode from working. Web pages are black and while by default, so anything with lots of bright colors is something you have to do intentionally. Animations are also something you have to add intentionally.

It really seems like just by not breaking the defaults (I.e., no work at all) your web page should do a decent (not perfect) job of being accessible. But we're so obsessed with making things shiny and swooshy that we've lost sight of that.

>"Accessibility costs money" is a popular thing to say, but I'm not convinced that needs to be true. Okay, fine, captioning/transcribing videos I'll give you,

Even that one is overstated. Sure, taking some existing video, and treating it as the only representation of the content, and then trying to transcribe it -- that's expensive.

But virtually every such video (esp. lectures) intended for conveying information is going to correspond to some text equivalent, and they can just post that in a place that's easy to find. Not only is it cheap, many users who can hear will prefer that version.

I think it's just a widespread attitude problem (for lack of a more refined diagnosis). It's not just big institutions, but discussion forums where some users will stubbornly link a video as their only citation, and won't even take the time to summarize the key point they think it's substantiating.

Can you elaborate why do you assume that such videos are likely to have a text equivalent?

You bring up lectures as example - I certainly don't have transcripts of lectures I've given, and neither do most professors/lecturers/whatever that I know; a few of them have most of their talk content in their slides but that's a horrible practice that distracts from effective lecture or presentation; in general all the non-audio material is intended to be a supplement to the talk and either are not meaningful without it (e.g. illustrations) or are not representative of the talk (e.g. a textbook chapter that's mostly about the same topic, but different). The recorded audio (if it'd be recorded) would literally be the only copy of the content of that lecture in existence.

The same applies for many other genres of video content. Most videos aren't scripted, and thus no script exists; heck, even videos that are clearly well prepared, staged and filmed with multiple takes (e.g. many of "youtube creators") generally don't have a script beforehand, the textual content is improvised on the spot and doesn't exist in written form unless it gets transcribed.

Interviews and podcasts are other good examples - as you say, many users who can hear would prefer to read it, I certainly would, but the obvious reality is that the textual version of those things does not exist unless it gets made, and making it takes much more time than recording the interview or podcast in the first place.

I was specifically referring to videos intended for conveying information, not entertainment. If professionally done, it has a script. If a college lecture, it has a corresponding textbook exposition. And you've seriously never written up any equivalent to any lecture content? It's all extemporaneous, all the time, and you can't spare the one time to write it down?

We don't have a tradition of teaching from a particular textbook (some universities do, some don't) so generally a lecture would include pointers towards chapters in multiple different textbooks, none of which match the contents of the lecture exactly (i.e. they're supplementary material, extra reading); and even if some lecture was based on a particular textbook, that text (unlike the lecture video/transcript) would be something that couldn't ever be published with a video because of copyright issues.

For my own teaching, no, I don't write up a "script" beforehand, I prepare content and plan for the topics and key points that I intend to cover in this lecture (and the next one, if we go quicker than expected), but the actual content heavily depends on how the students react, what they are (mis)understanding, what are the questions, etc. I don't consider well-scripted lectures a good thing, the lecturers that I know who are more into "reading off a script" give quite weak lectures IMHO.

Preparing in-depth textual material would seem a waste of effort as students would get the same content in the lecture. I wouldn't use it for other students since I'd anyway never give the same lecture twice - research is progressing fast, so my 2016 content is dated now and this year's content will definitely have to be rewritten (and the course restructured) next year. Admittedly, that's context-dependant - my situation is uncommon, there's a lot of teaching that involves lecturing the same introductory topic for many years off of a classic textbook to multiple larger audiences, and in that context your arguments would definitely apply.

But that's actually all offtopic.

The main issue is that none of this is equivalent to the transcript. Nothing of what you propose would make the video accessible to a deaf person. A textbook chapter or the lecture materials are alternatives to the video, it helps making do without the video, but doesn't make accessible the part of video where the lecturer is writing something interesting on the blackboard and explaining something that you can't hear.

I think you're the one who's demonstrating an atypical case here; most lectures aren't presenting on some rapidly changing topic, and even if they are, there is some Wikipedia text that is kept up to date.

>The main issue is that none of this is equivalent to the transcript. Nothing of what you propose would make the video accessible to a deaf person. A textbook chapter or the lecture materials are alternatives to the video, it helps making do without the video, but doesn't make accessible the part of video where the lecturer is writing something interesting on the blackboard and explaining something that you can't hear.

That's overstating it. The relevant metric is, if some deaf (or video-hating like me) person wants to learn the material, do they have a useful option? The fact that you can't make that specific video useful isn't relevant. Even pointing to some text that hits the same key points is major step up, and is trivial to do, and yet most refuse to do, just like most refuse to provide the one insight that they're making me watch a three minute video to hear.

By not breaking the defaults you make something ugly. By making something ugly people won't come again. Hence accessibility does cost money. Add the occasional ungrateful guy who will sue you because you forgot a caption and I get why people don't try to accomodate more to a niche that won't be lucrative anyway.

Black text on a white background with the occasional underline is ugly? God help you if you ever have to read a book.

Making an accessible webpage to present some content is easy. Making an accessible web application is a completely different problem.

While on the surface this is true, the amount of work required as a developer to learn how to do this is insignificant compared to the total time required to really understand your craft. While you may have to spend more time testing accessibility if you want to use the latest features in the bleeding-edge versions of JavaScript and CSS (or whatever language you're using which compiles down to them) or WebAssembly, you'll probably spend more time on browser compatibility testing, too, with those technologies (or you'll take the IDGAF approach).

When you really dig into it, though, most of the accessibility issues for the UI of a web application are still among the things you have to know to present accessible content on a website. In either case, the important point is to know when you're pushing the boundaries so you can make an informed decision about your testing requirements. It's just another metric to consider, like browser compatibility or mobile presentation.

By making things accessible to disabled people you also make them accessible to computers. This can be a great asset, for instance in automated testing (much easier with accessible ui) or indexing (with captioned video).

Just thought it would be worth pointing out some other costs we don't typically consider here besides development costs is litigation costs...

The most troubling wave of ADA litigation is just beginning to crest. The ADA’s next frontier—and next target of litigation—is the most innovative segment of the domestic economy: e-commerce. The latest trend in ADA litigation is suing commercial websites that aren’t sufficiently accessible to the disabled—because, for instance, they lack assistive technologies for the blind or hearing-impaired. Even though the ADA was enacted before websites became ubiquitous, many courts have interpreted the term “public accommodation” in Title III to encompass the Internet, and will entertain suits applying to it. In 2008, Target paid $6 million to settle a class-action suit brought by the National Federation of the Blind charging that the retailer’s website was allegedly insufficiently accessible to blind customers. Target also paid nearly $4 million in costs and attorneys’ fees to the plaintiffs. Why would Target pay $10 million to settle a case when the law is unsettled and its culpability far from certain? Class-action lawsuits are particularly expensive to defend, and because the potential liability is aggregated to reflect the entire class (all blind consumers, in this example), the financial exposure for a firm if it loses in court presents an unacceptable risk to most corporate defendants. https://www.city-journal.org/html/ada-litigation-monster-151...

This also happened with Netflix over captioning: https://www.nad.org/2011/06/16/nad-files-disability-civil-ri...

Netflix now does the right thing and captions everything.

Was there a tradeoff involved there? Is there content that is not in the Netflix catalog today because of the costs of closed-captioning the rest of the catalog?

If that is the case, are Netflix's customers better or worse off, individually and collectively? Is society better or worse off? (I don't have a clear answer, and I'm not sure there's an objectively clear answer, but I do think that there are tradeoffs in these discussions that are sometimes hidden/ignored.)

I am not aware of any content that got ditched because of this. I imagine only a Netflix admin type person from back then would know something like this.

They only have to provide it, if it originally had captions. They didn't have to caption stuff that never had captions to begin with, but they went ahead and captioned everything, pretty much, and if you look at their new self-created shows, they are typically multi-lingual(multiple voiced languages) and multi-captioned (multiple written languages).

I would say, it forced them to deal with becoming a global provider and not US/English centric like they were, which I think we can say has been good to their business overall :)

How many times have you selflessly made your product accessible? It's easy to point fingers and judge people, but it is genuinely difficult to serve people with every conceivable disability.

Do you optimize the prose on your websites for people with IQs under 75? How exhaustive is exhaustive enough?

I've spent considerable effort on making things accessible in my life, and I'm sure it can cost you your entire product when you're just starting out.

Edit: I think the limitations apply to products which are marketed to the general public. If you know your existing users are struggling with an accessibility bug, then you know what you have to do.

Writing documentation for the equivalent of 8th graders is pretty common for any writing, so I made a habit of doing that a long time ago. It's like coding - if you're too clever, it's hard to understand and read later.

How hard is it to really use reasonable font sizes and contrast ratios? How hard is it to add a few more tags to your site? How hard is it to caption videos as you're making them (most time you're working from a script anyways).

If you're not starting these good practices from the beginning, yes, it will be harder to do all at once later. But if you start doing it from the beginning, it is pretty easy to do. Just like testing. Just like coding standards. Just like design patterns.

It's easy to accuse people of pointing fingers and judging people, too, and genuinely difficult to make high-quality, thought-provoking Hacker News postings.

(Your comment would have been much better had you left out the rude accusations.)

Releasing content in to the commons for free //should be// an exception; however if someone else wants to add to that by providing captions in a standard format there should be a way of combining that to achieve a further enriched commons.

The truth is there is a cost associated with all of this. Example my current job I brought up issues of font scaling, screen readers, etc. They care to make it good enough BUT not enough to invest significant time, because we need MVP. People won't accommodate the minority unless they are one, unless they have to, or unless they really really care and can convince their boss. This is an unfortunate truth of humanity or business.

Personally I very much care. But I don't get to call the shots.

I was going to make this comment on the parent comment but you really tee'ed it up for me perfectly.

Not doing basic accessibility on the web is just mental laziness, plain and simple. I have to strongly disagree the the implied point in your post that it requires investment of any significant time.

You can get 90% of the way to "good" just by picking appropriate font sizes and colors, doing halfway sane IA, and probably most important just using semantic markup. Adding text info to images, aria tags, etc are very minimal efforts if you simply have it in mind as you work.

None of those things require any extra time except that people need to care enough to read some documentation and watch a couple youtube videos which is a one-time up front investment of 1hr or so (not saying you are an expert after 1hr but you can definitely do "ok" with 1hr of research and learn as you go from there). a11y gets more complicated when you start doing heavy js with custom realtime interactions but even then you can get 70% of the way there with very little effort and it is a bit of a red herring because how many people are really working on fancy modern SPAs in their day jobs?

There's an argument to be made that the aria data can be leveraged by your test automation as well.

Code that a screen reader can't decipher is pretty hard for test frameworks to figure out, too.

> I have to strongly disagree the the implied point in your post that it requires investment of any significant time.

Totally agree. Basics like alt tags on images, wcag contrast friendly colors and semantic tags to let screen readers know this is a repeated menu, this is content, etc... take very little additional time and help so many people. Even in SPAs these items are basic.

"this is content" sounds extremely useful for everyone. Curious if there is much abuse of accessibility markup to trick users into clicking ads.

Hey, ever since we started using REMs it made scaling much easier as well. There are times when we had to work around for example bugs in Chrome with font scaling and transform under certain conditions which made chrome resize things incorrectly, but only chrome.

Its little things that take up a bunch of time. In theory we're already 80% of the way there, but the last bit is what makes the big difference.

Black text costs more than grey text? What, are you paying for ink?

In my experience companies don't want to pay for it up front. So they end up paying much more later (after the lawsuit).

On the other hand, catering to ignored niches is a good business plan. If you can own a small segment, you can make more money than uselessly going after the center of where your entrenched competitors are.

Once the niche is conquered, this can be used to go after the less nichy segments.

See "The Innovator's Dilemma" by Christensen

The problem is that this niche is not stereotypically a very well paying niche. The intersection of high earners and disabled people is quite small (and the intersection between lowest 20% of income earners and disabled is quite large)n So, there's not really a lot of money (if any) to be made by focusing solely on this niche.

That's why the ADA and various government laws came into existence - nobody was catering to the niche since it wasn't lucrative enough.

I made good money in the compiler business by catering to niches that were completely ignored by the other vendors, large and small.

I'm also happy to get any accessibility problems in dlang.org and digitalmars.com fixed, if anyone wants to notify me of any problems.

That may be good for one individual business, but not good for the segment of the population that's disabled.

For example: restaurants. Take a world where restaurants have to comply with ADA regulations versus a world where it's expected that someone coming up with a business plan for a restaurant that caters to the disabled. It's the difference between a world where the disabled can go to restaurants or where they can got to a restaurant.

I live in a central European city full of restaurants that would be sued out of existence if they were in the states for ADA violations.

The ADA also means that a lot of hole in the wall establishments you see in Europe simply can't exist in the states. Society is poorer for it.

Is it? The disabled are part of society, too.

That's hardly the biggest problem IMO.

What bewilders me most is the number of engineers and designers who can't empathize with how their users might interact with the unspeakably bad UX they're putting together.

Sometimes I have a hunch that inaccessibility is what costs money. A basic informative HTML web page is cheap to write and host. The deluge of swirling graphics, icons, and microscopic pull-downs, are what cost money to create.

I have been building software UI's for a decade and I absolutely agree.

I really don't get it. Basic web-pages are simpler, easier, faster, smaller, and provide data in a more manageable format.

Sure, there's some things that work better as an SPA, but those are extremely rare.

Basic web pages are less appealing to the mainstream, so they capture fewer eyeballs there.

Example: https://www.debian.org/ is a simple website, designed for broad accessibility, but it doesn't look 'slick'. If you were looking to choose an OS, this website wouldn't make you go 'wow'.

You are correct, but that's kind of my point.

To me, a website is a tool to get something done. I don't want a website that "wows" me. If you really want to wow me, then you are likely trying to sell me something that I probably don't want.

Accessibility is about letting people get shit done, not marketing to them.

If basic webpages 'sold', then marketers would use them. Webpages that 'wow' work, that's why people use them. It's not based on gut feelings either - there's lots of research in the area, for example A/B testing.

People say they don't want shitty news either, but the news that is most popular is pretty low quality, sensationalist tripe.

Your missing my point: If your goal for a webpage is to sell, then glwt. I get that they are a thing, but they are pretty useless to me, and good luck making marketing material that excludes people that want to give you money.

Webpages to me are tools, not marketing material. If you want to use them for marketing, then great! Just don't waste my time trying to turn a tool into marketing material.

Webpages that are meant to be useful (like Debian makes, etc) should be accessible, not promotional. The webpages I use are tools to get a job done, not to browse for advertisements.

> and good luck making marketing material that excludes people that want to give you money.

You're completely missing my point. Web pages are the way they are because they pull eyeballs. You are a single data point. You don't like slick webpages? Fine, you're an outlier. There are people out there that don't go online at all. They're also an outlier. You each find niches to cater to you, but you're not the majority case, and if you're interested in eyeballs for whatever reason, then dealing with the majority case is in your interests.

It's not just marketing either. Compare Arch's wiki (simple Mediawiki) to Debian's. Mediawiki is more complex than Debian's simple pages, yet it is far more readable. Even as 'just a tool, not marketing'[1], this heavier webpage is a better webpage.

[1] marketing isn't just selling stuff. for example, plenty of free software projects provide giveaways to conferences to raise their profile

Yes, if you make a mess and bring in some accessibility compliance people that have to suggest all kinds of shitty workarounds it will cost you money. If your devs don't know why those shitty workarounds are there they will break it all again in a next release. If you just use semantic HTML from the start you'll have a more robust product and less maintenance in the long run.

Oh, and ARIA rule one: don't use ARIA, use the native HTML equivalent. Rule two: Only use ARIA if you can't express your intent in native HTML and make sure you know what your code is doing, don't just copy paste some ARIA example from another project or random site, lots of ARIA in the wild is wrong.

I'm a blind developer and accessibility consultant. Accessibility consulting is a good business to have these days, but I hope my work will be obsolete one day :).

Your point about profitability assessment is an excellent one. I recently spoke to the CEO of a company that makes ebook reader software. This CEO has issued multiple open letters about accessibility, claiming that his company cares a lot about making its products accessible.

But in a conversation with him about a new text accessibility tool, he said that if he can't "pass on the cost to his customers", he is unlikely to offer it to his customers.

This shows a complete misunderstanding of what accessibility is. If his company could make more money by including a new feature, then integrating it wouldn't be "accessibility" – it would be "usability" or "good design".

Accessibility is (almost), by definition, the stuff you do to make your product usable even though the time you are spending does not pass a typical cost-benefit test.

And the point of ADA lawsuits is to make sure that the cost-benefit does line up, if legal fees and judgments are included.

...screen readers just need to get better.

TFA doesn't relate any tweets about screen readers, and identifies many easier tasks as being more important than screen reader compliance.

It would be nice if web authors had a tool for that compliance that wasn't expensive and obscure like the readers themselves. (If they weren't obscure, we'd just file some PRs and be done with this.)

NVDA [1] and VoiceOver (iOS and MacOS) are free.

[1]: https://www.nvaccess.org

Where do you draw the line? Berkeley recently [0] had to pull tens of thousands of free education videos, because California law required that they be captioned, and they couldn't possibly caption tens of thousands of videos. So they just pulled them. I'm on board with an E for effort, but I find what I've described unacceptable.

[0] https://reason.com/blog/2017/03/07/berkeley-deletes-200000-f...

I think people underestimate the difficulty of getting this done in a University environment, but I also think people are too quick to side with Berkeley in this particular case. One of the points made by the DoJ was that Berkeley makes resources available to faculty and staff to do the captioning, so, in theory, the captioning could have been done as the videos were made (at least those which were made in the last couple of years), and it should have been done as they were posted (again, at least those posted in the last couple of years).

So, the problem is getting the faculty and staff at Berkeley (and nearly everywhere else) to take the requirement seriously. Many of the people working to make content accessible are not in a position of authority over the people creating the content. In some cases it's a battle to educate the people who are in authority regarding the legal requirements and the consequences of ignoring those requirements.

As much as I wish that content didn't have to be pulled because of accessibility issues, sometimes there is no other way forward.

It is worth noting that the Berkeley case was federal law. California law does make the requirement for state Universities to comply with the ADA more explicit, but the US DoJ isn't in the habit of investigating violations of state law. The DoJ's letter to the University cites the ADA and various portions of the US Code: https://news.berkeley.edu/wp-content/uploads/2016/09/2016-08...

> it should have been done as they were posted

This was not something they where required to do?The implication here is if you add requirements to free content, institutions just won't bother - the material was only released due to the low bar to do so in the first place.

> sometimes there is no other way forward

There is if you change the law, which is what I think parent was implying

This is where it can be difficult for people to understand the culture in which people are operating. From the outside, a public University is the ivory tower, but from the inside, it's just short of chaos. Sometimes faculty have direct access to post this stuff and either don't understand the requirements or don't care. Other times the staff who post this stuff don't have the support to stand up to faculty when they're told to post it.

The University is not removing all of their content, and they plan to continue to add new public content. It would definitely be a significant undertaking to make 20,000 audio and video files accessible. I'm sure the people responsible for the content will consider prioritizing that undertaking and possibly seek funding to get some of that content back out there.

Something else that is missing in their discussion of requiring University credentials to access the content is the fact that the same requirements apply to content they distribute to students, faculty, and staff. The difference is primarily in the likelihood they would be sued, and the fact that they would have a much easier time finding the funding to make something accessible if a student needed it.

Yes, you could change the law, which would theoretically benefit the people who could access this content, but would completely set back the few gains we've seen in web accessibility (assuming we're not also talking about everything else the ADA does).

Or you could set priorities for the content and fund the effort to make it accessible if it's really worth making it available. Fund research into improving automatic captioning/transcription, put your students on the path to better jobs, and improve the content for everyone.

Glad to see the lines blurred even more. Accessible design isn't about changing things to check off items of a list - your users' ability lie on a spectrum, and our job is to make sure we aren't ignoring vast sections of that spectrum.

When trying to sell people on Shade[0] I like to explain that good contrast isn't just for people with a visual impairment, but important for folks on old monitors, classroom projects, or even looking at their phone in direct sunlight.

Mega props for Safia[1] for posing this question, the responses in here are super eye-opening.

[0]: http://halogensoftworks.com/shade/

[1]: https://twitter.com/captainsafia

I have Spinal Muscular Atrophy and due to weakness can only use a mouse + on-screen keyboard.

My biggest gripe is sites that load with focus on an element that doesn't allow me to scroll down via the down arrow. This forces me to click the middle of the page to continue navigation via OSK.

Bad: https://circleci.com/gh/wbond/asn1crypto (can't even page down) https://pypi.python.org/pypi (new pypi might change this)

Good: https://www.youtube.com https://www.quora.com

This sounds like an excellent opportunity to make an extension for Chrome or addon for Firefox to clear, reset, or set focus on load.

You forgot one of the most unfortunate offenders: Google.

I made FocyOverride for that, still need to update it for the WebExtension API

>Many replies, especially from people with dyslexia or cognitive impairments, were about large chunks of text.

>Huge paragraphs. A page on Wikipedia often consists of many long paragraphs with long sentences. I lose my place within seconds.

I have often felt like a lot of web content writers and editors could benefit from reading books like Stephen King's On Writing. Wikipedia in particular is often criminally unreadable when you get to deep-topic articles that are generally only seen by experts in that field. Which makes sense, but I would hope an expert could "dumb it down" for an encyclopedia.

Breaking something down into paragraphs with stupid-easy topic sentences doesn't just help out laymen, it also makes your content just more readable and navigable in general. Plus it's perfect for the web, you can stick an in-page anchor tag there and have a table of contents at the top of your page.

i'm curious to know: if you have a disability, what's the hardest thing about browsing the web?

First thing that comes to mind: CAPTCHA. Not all of them have an audio option. If you're blind, you're out of luck. Not to mention, CAPTCHAs these days are so difficult that I feel like robots will soon surpass us at recognizing these oddly distorted characters and words.

Interestingly, the article only mentions CAPTCHAs at the bottom. I wish there was more innovation and theory about CAPTCHAs, I'm personally very fascinated by them, but it's a very difficult topic that is rarely treated rigorously. How do you quantify "hard to recognize for robots" etc.

I think ultimately we need to move away from CAPTCHAs and toward something like a "proof of work" which still makes spamming/botting infeasible, but doesn't require a lot (or any) thought from a human.

There are still very important aspects of this to solve (I don't want every website draining my mobile battery doing constant proof-of-work calculations every pageload), but with ML getting better and better and the ultimate goal of passing a touring test being in the interest of multiple unrelated groups, it's only a matter of time before CAPTCHAs are mostly worthless.

Or an outright payment if you don't want to / can't perform that 'work'. As a bonus this might allow for the micro-transaction fee that will kill ads (yeah right, that is going to die a slow death).

That's already a thing. Quite a lot of CAPTCHAs now are just "click the lone button" where it determines if you're real based on timings, mouse movements, and other things.

> CAPTCHAs these days are so difficult that I feel like robots will soon surpass us at recognizing

They already do. That's why they introduced No Captcha[0] in 2014, and Invisible Captcha[1] earlier this year.

[0] https://security.googleblog.com/2014/12/are-you-robot-introd...

[1] https://arstechnica.com/gadgets/2017/03/googles-recaptcha-an...

Disclaimer: I work at Google, but not on reCaptcha.

Even "No Captcha" is rather annoying as I'm almost ALWAYS asked for additional input. The checkbox alone never does it for me. Why do I seem so bot-ish?

You are a bot. You just haven't become self-aware yet.

Says someone who's only a part of a simulation...

ReCAPTCHA is OK but it still falls through to the inaccessible traditional CAPTCHA enough that we banned it and other similar solutions on gov.uk properties: https://www.gov.uk/service-manual/technology/using-captchas

Which gov.uk services offer commenting facilities? Would you be able to share how effective these methods have been to preventing spam while allowing legitimate comments?

Every non-service page has a feedback form, services need to provide feedback mechanisms[1] and the blogs have a commenting system.

Basically, none of these publish immediately. Feedback goes into Zendesk typically, and everything on the blogs are premoderated. Spam happens but because it doesn’t immediately show up on a gov.uk property it’s minimal enough to deal with manually. Basically, better that than denying a section of the population the right to comment.

[1] https://www.gov.uk/service-manual/design/feedback-pages

Ah thanks for responding. The design choices there make sense for a government website where inclusivity is important.

CAPTCHA is even difficult for people without disabilities. The other day I was attempting to setup an account on a website that used reCAPTCHA and I had to go through 5 different attempts before it worked. The words were too blurred together and when trying the audio it played some noise behind when it was speaking the letters so I kept not being able to understand it.

CAPTCHAs are absolutely dreadful.

As a visually impaired person, I can honestly say one of the best things is when accessibility is built into application frameworks.

It's not perfect but it gets you 90% of the way there in a lot of apps that wouldn't implement the features otherwise.

For example, most apps that are built with Microsoft frameworks automatically support high contrast and narrator.

The super awesome part about this for me is if accessibility is built in at the framework level I can develop start to finish with the accessibility features enabled. I don't have to struggle with an inaccessible app until the features are"in".

One thing I realized about writing maintainable code applies just as well to designing accessible interfaces: the right habits get you 80% of the way, with no real cost beyond developing the habits. Getting into the right habits is an O(1) investment that pays off by making everything you produce more accessible.

Adding alt tags to images, using high contrast colors for text, writing clean, well-structured markup... all these things don't take significant time on top of your normal work as long as you do them right away. They also have additional benefits like making the site easier to parse for search engines.

Yep, the 80%-90% level is pretty easily met by doing those along with using the native controls (buttons, links, etc.) properly. When your designers hand you a custom interactive widget, you can add a good chunk (50%-100% extra effort) to your estimate to make it accessible.

I struggle getting designers to consider how a thing is supposed to work without a mouse for instance.

a lot of designers I've worked with don't come from a web development background - they typically come from print design. They know how to make things look good, but when it comes to user interaction, or web specific functionality they don't know that they have to deal with much, much more than what you can see in the first instance.

You can't just design something and have it look good, you need to consider what happens in x, y, z scenario, and if you don't have experience, you don't even know those things even exist.

I'm a dwarf with disability in limbs, my biggest concern has been navigation in smartphones/apps; especially since they are growing in size. Fortunately I have good engineering experience and was able to customise my devices (android: pie controls) according to my needs. I wonder whether the reason we didn't see much tweets in the post for people with limb disabilities are because they weren't able to access twitter in the first place.

I must credit smart watches (Android wear/ Apple Watch) here, I'm sure it helps a great deal for people with disabilities. Accessibility is one good reason for not to let smart watches die. I'm planning to write a blog post on this context soon.

Simply put, things that are better for someone who needs accessibility are also better for everyone else.

Maybe I want to watch something while muted. Maybe I just don't WANT your site screwing with my font size. Maybe it is a lot easier to tab between things than using the mouse. The list goes on.

> Simply put

But in the real world, this isn't always the case. The article itself is a great example. It uses giant fonts and lots of whitespace, which is good for people with poor eyesight, but it leads to a choppy, hard to follow article. It also forces you to use navigation to follow a chain of thought.

I said "needs accessibility", not "needs large font". Accessibility means that if someone needs to set the font to size 100, they can and the system won't break because of it (e.g. text won't be cut off with no way to see what was lost). It doesn't mean that the default choice is some kind of lowest common denominator that is weird for everybody.

The only exception where defaults must be pessimistic are the settings menus themselves. For instance, a button that increases font size must be large enough for anyone to see; a button that changes language cannot be only labelled with the text of a foreign language.

Question for all the people claiming basic accessibility is low effort...

Following your low effort implementations of basic accessibility have you actually tested your website/app with a screen reader or other accessibility tool? Or have you just used some semantic markup, scattered a few aria tags and called it a day?

I have worked on a mobile phone app where the client dictated certain accessibility requirements up front. I can tell you right now if you aren't testing in a screenreader then you haven't achieved basic accessibility. And from my experience, once you start testing with a screenreader you will quickly discover that all those assumptions you have about "all you've got to do is add a few alt tags, pick sensible font colours and use semantic structure" fly right out the window.

Every single app screen we did had an additional test pass by a tester who would use the screen via accessibility tools. The app as a whole had several accessibility test passes during the dev cycle. Both of these test stages would always throw up new bugs that would often require significant rework to get working right with the accessibility tools.

I'll grant that my experience here is in mobile apps, and I accept that the available accessibility tools for mobile are limited and perhaps that was part of our challenge. And maybe the ecosystem is more mature for websites and desktop apps. So this is a genuine question for those claiming it's low effort. Have you actually tested it?

If you haven't actually tested it, perhaps your websites/apps are part of the problem, you just don't know it.

I personally think developing for accessibility is a good thing, and I always do it when I can. I try to follow best practises for accessibility even if the current project owners don't mandate it. But at some point you can't just follow best practise and hope it works, you've got to commit to testing it, and then commit to raising bugs against it, and triaging them through the bug process, and at some point you'll be at a standup 2 days before a release with 10 bugs on the board, 6 of them accessibility bugs, and only time to fix 4. Guess which ones are going to make it into the release.

If my experience follows for other domains, to claim that it has zero or minimal cost is ludicrous. Developing and testing for working accessibility comes with significant cost and therefore of course it's a business decision.

VoiceOver is built into iOS and Talkback into Androins. These tools are free and already available in your environment of choice! If as a developer you can’t even spend the 5 minutes to turn it on and run your new feature through it then you’re abdicating responsibility to the point that you’re failing at your job.

You've entirely missed the point of my post, it makes no difference if the tools are built in or how quick they are to activate. Have you personally actually tried turning these tools on and testing your app?

My point is that I believe that all the people claiming it's easy are only doing the 'best practise' implementation (which I agree, is easy and doesn't add much time) but without actually testing that it all works smoothly they haven't finished and are just part of the problem.

My point is that from my direct personal experience with similar tools, it does not take 5 minutes. It takes weeks of additional testing and bug fixes to get a large app working smoothly with accessibility tools, after you've followed the best practise for the initial implementation.

Yes, I test in VoiceOver and Talkback (although for websites, not apps to be fair). But I dispute the assertion that it takes weeks. It takes a small amount of time per feature to test, and certainly no more than testing on multiple versions of the OS or multiple screen sizes.

If on the other hand you’re throwing untested features over the wall to a QA team, then yes, it’ll be inefficient. That’s the nature of the beast.

Video captions are also very important for non-native English speakers (or better say, those who cannot really SPEAK this language) because it's often hard for them to discern English words by ear.

Fonts are a big issue, but it's not just the web. Two things I hear frequent complaints about are:

- low contrast overly thin and small iOS fonts

- low contrast overly thin very small Mac fonts

This includes myself but I've had this conversation with multiple other people. My eyesight isn't bad enough to require reading glasses but it's not perfect, and the microfonts throughout Apple software gives me eyestrain quickly.

It seems like the glaring white UI and microscopic gray fonts in iOS 7 and OSX Yosemite onward were designed for other designers, and not for users or usability.

It’s worth pointing out though that iOS has extensive options for enhancing accessibility, like increasing font size and contrast, reducing transparency, removing animations, and so on. To me, this seems like a reasonable compromise.

I made all of those changes on a relatives iPhone and they still struggle to read anything on it.

¯\_(ツ)_/¯

Unfortunately, many many apps ignore these settings wholesale. I actually did a survey of news apps to see which ones offered any text accessibility options at all (or respected the OS level settings). The results are not good, especially among tech company news readers.

https://hackernoon.com/the-importance-of-text-accessibility-...

If you make a design because it looks good and not because it works well, then you're an artist, not a designer. A designer has to meld form and function. Pencil-thin light grey fonts are a fashion fad, not a thoughtful design choice.

> Fonts are a big issue, but it's not just the web.

Excellent point, and in iOS apps it's an even bigger problem because third-party accessibility tools cannot affect the way text is displayed in other apps. Neither mobile Safari nor mobile Chrome supports browser extensions that are always-on, in the way that their desktop counterparts do.

Instead, you have to tap 2-4 times to activate an extension on every single page you load. And of course, if you want to provide more accessible text in an app other than Safari (Kindle, NYTimes, etc.), there is generally no way to do so.

At least with NYTimes, someone could access their mobile site through Safari. Amazon, on the other hand, blocks access to their Kindle web app from nearly every type of mobile device.

I often browse in bed, and I just can't listen to a video. Other times, I slowly read web page between compiles and don't want to listen to a video. I almost always prefer the transcript.

I also find small fonts difficult because many times I sit farther back to give my "perfect" young eyes a rest. Small fonts are difficult.

I block ads to avoid distracting animations and sounds, and I have no cognitive impairments.

It seems like these guidelines are important: the web isn't an art project, it's a communication medium.

I'm NOT disabled, and I hate videos without a transcript.

Most videos suck. Giving me a transcript lets me read everything quickly and determine if the video is worth spending an hour on.

I'm surprised not to see images-of-text being called out here. This is a huge issue on Twitter, since people work around the character limit by using images with lots of text. I've even seen this done on #a11y twitter chats, amazingly.

Twitter lets you add alt text to images, no problem there. Just people are lazy...

Yeah, never see those used! Do you know if they can be added after the tweet is posted? Or if the text is used in search results?

Ah, no idea, I just use my default client (Echofon) to do it when I post an image.

Majority of people wouldn't mind making their sites accessible for the disabled if they had necessary skills to do so. Problem is that almost every Web Designer, know close to nothing about designing websites for accessibility. In fact, most Website Designers can't even make a website to be usable by people with no disability. Focus is on making websites to look fancy.

Another thing I have noticed is that a chapter about usability of websites is treated as an extra. Usually at the end of the book as additional reading. Maybe we need to regulate the industry and make it impossible for people to start practicing without proper training. There are codes of conduct that a lawyer, accountant or doctor has to abide to, but there is none for a Website Designer. No implications whatsoever for not making websites to be accessible. They end up blindly ignoring accessibility because they weren't trained to do it.

Fining companies won't help because 99% of the companies are headed by people who don't need to know if the website is accessible to the blind or not. They just trust the designer to do a good job. The only time they will know they are supposed to make their website to be accessible is when they are getting sued. Problem is that regulation will greatly reduce number of practitioners and greatly increase the cost of website development.

> It’s really easy to test, just view your site in greyscale.

This is misinformation: some common forms of color-blindness (protan) affect perceived luminance.

Use the Web Content Accessibility Guidelines. Yes, they are constraining. You'll quickly realize that the easiest way to comply is not to rely on color to convey information.

The U.K Home Office has put together a pretty neat resource to help with accessibility across the varying needs of web users, they've put together a bunch of posters which clearly outline the Do's and Do not's, all in one handy Github repo https://github.com/UKHomeOffice/posters/tree/master/accessib...

It's not just the web. I've long been frustrated by the legibility of tiny fonts on laptops with even medium-res screens. Now that Apple has introduced an even higher-res 5K display on the iMac, I find it almost impossible to read some system menus and popups.

When did it become OK for Apple's long-vaunted UI become so user unfriendly? Jef Raskin must be rolling over in his grave. This is definitely NOT "computing for the rest of us".

My eyesight is completely OK, but I crank up the font size everywhere. Both Reddit and HN are at 150% magnification, every time I see them on a new device I'm surprised people feel comfortable reading such small text.

This. I've been recently wondering if I either sit too far away from the monitor (~60 cm) or my screen has too much pixel density (1080p / 21.5 inches), Because my vision is almost perfect and I can barely read the text on HN without zooming in.

ADHD here. Glad I read this article, it's vindicating to see other ADHD people complaining about animations and autoplay. My God, if there's any autoplaying anything, I cannot read your article. I cannot.

I even had to hide the friends thing in Spotify (the right sidebar that updates what your friends are listening to) by dragging the window slightly off the screen. (Recently found out that you can disable it in Settings which is great)

Would it be difficult to make a program that sits in the audio stack (probably on Windows) and tries to run voice recognition on everything coming over the line and then renders anything that sounds like speech at the bottom of the screen?

Yes. Youtube tries (tried?) to autocaption videos, and the results were infamously bad.

Yes. Voice recognition for arbitrary voices, accents, and lexicons is not as reliable as you imagine, much less in real-time.

Doesn't asking this question on Twitter affect the result, as some people with disabilities might not be able to access that service in the first place?

Seems like captioning is a huge issue. Isn't there an audio equivalent of a screen reader?

Not really. I mean, there are such things, but the technology isn't good enough (yet?).

Text-to-speech generally works well, it produces good results almost always. If you try hard (or really need to), you can understand even if it tries to "speak" the text assuming the wrong language.

Speech-to-text works somewhat well under certain conditions (e.g. known speaker to which the system is adapted, known domain of text, no accents, no background noise, etc), and even then it gets quite a few errors; if you're just running it on random youtube videos, the results often are totally off.

This is an interesting area, with lots of opinion on implementations. It gets messy, and quick.

So it's normally part of the ADA to make things accessible. But with building, one can retrofit an older building that wasn't accessible with a certain percentage, and still avoid ADA compliance. I had that discussion in an architecture class, how to strictly comply with the law, whilst still skirting around it. The ADA as far as I know also applies to online as well, but the percentage change of a building doesn't really have an analogue with online.

The justification was purely money - disabled people work lower wage jobs, and aren't worth the money spent in upgrading a facility. It's disgusting logic, but there you have it.

I also think of DRM. It prevents end users from fair use (and also carte blanch copying).. Yet it also prevents converting the audio track to text with something like Sphinx. And with the deaf/hard of hearing, many sites prevent downloading and transcribing automatically. Youtube is trying with automatic transcription, and it certainly is a start. It's still hard, given the amount of sounds that are non-spoken that CC incorporates (sound of drums far away) (eerie music with footsteps).

And as mjevans said, what about an individual who releases content and doesn't have the resources to do ADA compliance? Is the correct answer is to ban said content? That seems to go in a really wrong direction as well. But we saw this earlier with (I forget which university) whom deleted all their videos primarily because they were dumped free online, without closed captioning. Instead, we all lost.

And as a developer, how do I determine how to write something that's disability friendly? It seems that flat text HTML with pictures and little/no JS seem to be the way. With pictures, include a alt text with a general description. With a video, include a transcript. Make sure the website will work effectively with Lynx because screen scrapers will tab through when reading.... But can I be sure that the above is correct? One thing I'm sure of, is that I'm missing a great deal of stuff. Red/Green or Blue/Yellow colorblindness, reduced vision, font issues (dyslexic fonts), Captcha handicap issues, and plenty more. How can I guarantee that I'm not just complying with the law, but makes my site usable? As far as I can tell, make a good attempt and wait for a lawsuit.

Then again, coming back to what was told of us in class - its an ugly "formula", but the disabled don't offer much in the way of economic gain, so why is there a reason to cater to them? (No, it's not what I believe, but a hard set of rules that people like Architects consider with regards to pricing with clients. I see no reason why this financial rubric isn't also considered online.)

For a building I've always questioned if we should make it accessible, for safety reasons. When a building starts on fire and if you are in a wheelchair you are much more likely to die: no using the elevators, you can't use the stairs or the fire escape.

In my opinion we should require that all buildings be accessible on the ground floor(s). Those who medically cannot handle stairs should be given priority to the ground floor. (this includes any store that might want to sell to handicapped)

Of course wheelchairs are only one type of accessibility. Deaf and/or blind people can be expected to need some accommodation as well, but their needs are much different (and cheaper!) than the wheelchair bound.

In all well designed public buildings the emergency stairwells are actually isolated air-spaces (when the doors are shut). Their ventilation systems should draw from a location likely to be free of smoke and they should be at a higher pressure than every possible entry point so that they are positive pressure.

In such setups the /landings/ are life safety zones where those in wheel chairs can wait until rescue arrives to literally carry them down the stairwell (a stair sled might be a good for the rescuers).

It seems that internationally (recently the UK) laws and building codes are not as strict.

I usually prefer text over video, and the point that audio-only content isn't accessible makes for a very compelling argument to always provide a text version. So, in addition to wider reach, it makes it easier to consume the content at a pace you're comfortable with, as well as return later and easily reference specific parts.

For the motion problem, Safari actually introduced a solution a few months ago: the prefers-reduced-motion media query [0]. Hopefully other browsers will follow along and add support. Relevant issues per browser: Firefox [1], Chrome [2], Edge [3]. It doesn't look like any vendor has signaled interest, though.

I don't understand the wall of text point. Sometimes a topic requires a lot of nuanced points and clarifications, which might require long sentences and paragraph. I'm all for making content as approachable as possible, but I don't know if you can reasonably apply it to everything? I think seeing a few examples would probably help me understand.

For the small font size problem, browsers provide a solution! In Safari you can specify a minimum font size in Preferences > Advanced > Accessibility > [x] Never use font sizes smaller than [number]. Firefox also support a minimum font size [4], although the option is a bit hidden.

Too lazy to comment on the remaining points, but this was a really insightful post. I think we need more content like this to help us understand these problems. I'd guess most cases of poor accessibility are due to a general lack of awareness on the part of the development team.

My experience has been that making web apps accessible can be very challenging. There's not much good documentation or examples available, so as soon as you try implementing something more complicated than a traditional website, things start to break down.

In the previous paragraph I was going to reference existing w3c docs to explain my point, so I looked up their latest docs only to find that they've made some huge improvements! Check out the WAI-ARIA Authoring Practices draft [5]. It looks like now every single widget has simple docs and multiple examples. Even if I haven't implemented any widgets with this, just by skimming through, it looks much more promising than any of the previous docs I've seen.]

[0] https://webkit.org/blog/7551/responsive-design-for-motion/

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1365045

[2] https://bugs.chromium.org/p/chromium/issues/detail?id=722548

[3] https://wpdev.uservoice.com/forums/257854-microsoft-edge-dev...

[4] https://support.mozilla.org/en-US/kb/font-size-and-zoom-incr...

[5] https://www.w3.org/TR/wai-aria-practices/

Reply on news.ycombinator.com