Implementing Web accessibility guidelines for nondisabled users (2016) | Hacker News Reader

Implementing Web accessibility guidelines for nondisabled users (2016)

journals.sagepub.com

53 pointstommasoamici39 comments

Absolutely, because not all disabilities are permanent. They can broken into lifelong disabilities, acquired, temporary, situational, and chronic (potentially among others). Just think of how many people who can hear still use captioning on their TVs. Or how easy your website is to reading on a phone during a bright, sunny day. Or how usable your stuff is for someone holding a child in one arm. Accessibility (and thus, WCAG’s success criteria) helps everyone.

I don’t think it’s unusual that creators who have thought about accessibility have also thought a lot about UX, etc. So there may be some correlation there. But as others have posted, while there are some criteria more targeted at those using assistive technology (like screen readers), there are just as many things helping everyone else.

Besides all that, none of us are getting younger, and with age comes reduced mobility, dexterity, sight, hearing, etc. You never know what tomorrow brings. Someone who self-identifies as having no disabilities today may have a different experience tomorrow.

But then again, web accessibility is what I do for a living, so of course I’m a bit biased. :)

Famous pic about situational disabilities:

https://devblogs.microsoft.com/xamarin/wp-content/uploads/si...

(Google keyword: "microsoft inclusive design situational accessibility"; ironically, the canonical image comes from a guideline at https://www.microsoft.com/design/inclusive/ which is a PDF -- nowhere as accessible as web)

> people who can hear still use captioning on their TVs

Something that is rarely mentioned: foreigners who are learning the language. Captions are a turbo booster of learning, without them it can take years to understand what's up in TV when you're learning from zero.

Absolutely! Low literacy and illiteracy effects about 2 billion people in the world, and can include everyone using your primary language as their secondary language. Even if they’re getting by with running your site through Google Translate or whatever, the less you write in complex concepts, jargon, or regional idioms, the more likely they’ll be able to accurately comprehend your message.

And Microsoft’s toolkit is wonderful. My favorite part of working in accessibility for [big company] is that we don’t have business rivals in the a11y space. Everyone is in it to get better together.

Good accessibility is too often a competitive advantage in web products, when it should be the standard.

I often use a hypothetical case of a user who’s mouse just ran out of batteries when trying to pitch how important keyboard accessibility is. Most of the time my bosses become empathetic towards that situation.

> Just think of how many people who can hear still use captioning on their TVs.

I've given up on hearing people talk clearly in most shows and movies. Sound mixing is horrible and seems to be getting worse! The music should not be just as load as the speaker!!!!

This might just be the mix (and there might be second-order effects such as the mix changing as the mix engineers and producers get younger), but your ability to differentiate voices from background sound also depreciates as you age. The music can be substantially quieter than the background and still cause issues for people with age-related hearing loss (which is roughly universal), especially as they start to lose the higher harmonics that help us distinguish vocal sounds.

Facebook's representative at an accessibility conference mentioned that 30% of their mobile users do not use the default text size. This is a huge number, considering how hard it is to get people to change defaults. Features that are ostensibly for accessibility may be useful much more broadly.

I've seen this in the usability feature that my startup created. I initially launched on HN and got great traction in the lifehack community. Then I started hearing from people with disabilities who find our tech to be indispensable as an assistive technology. Our partners have reported 40% more reading on general-purpose platforms and 70% more reading on platforms for people with ADHD or dyslexia. (You can see what the reading tech looks like here, under Enhance Readability: [1])

Not all accessibility features benefit people who do not identify as disabled. But the ones that do are a win-win (and they help make the case for accessibility more generally).

1: https://unreasonable.is/how-to-stop-working-and-be-more-prod...

Unless I'm misunderstanding, this seems to be a totally correlational result. That is, they found that websites with increased accessibility tend to also be more usable. This is easily explained by assuming that developers who care about usability also tend to care about accessibility. It is more difficult to explain in a directly causative way, since many accessibility features, such as aria attributes, are completely invisible to non-disabled users.

There are definitely some core accessibility features that are great for non-disabled users, though, for example having text descriptions for images (it always irritated me that alt-text didn't automatically generate a tooltip, though I sort of understand why)

It's great to be able to mouse over images in Tweetdeck and (if the poster provided it) have the alt-text pop up in a tooltip so I can scan it to see if it's worth the time to open the image, and it's great to have textual descriptions of toolbar icons.

Huh, you're right, it doesn't anymore. It used to though.

I suppose it makes sense now that the web has gone from primarily being a document platform that's sometimes used to create simple applications to primarily being an application platform.

It's the title attribute on an image element that generates the tooltip. Did alt do that previously or was it always title?

MDN says not to put the same text in title and alt, as some screenreaders will read both.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Im...

IIRC very early on browsers would turn alt into tooltips, and then that functionality was split out into title. I understand why but I'm still bitter about it since they don't want you to use both.

I agree, however they did also run an experiment manipulating the same site (keeping design and layout equal and changing contrast levels). You can see two screenshots on page 616

There's also a 3rd category of users, the bots, and crawlers/scrapers can greatly benefit from some of those invisible accessibility features...

While this may be true we build (non-API) sites for humans. Just because bad actors may exploit tools for differently abled people doesn't mean it's OK to exclude the innocent to reduce ones costs.

No one suggested that, and not all bots are evil - there's still a number of useful web spiders that webmasters can benefit from, it's not just googlebot out there...

Certainly many things recommended for disabled users are of great benefit to non-disabled users, but there are also things that are recommended against for disabled users that the lack of can slightly hinder the usability of sites or applications.

One particular thing is that it is generally recommended against auto focusing in fields, but for sighted non-keyboard navigating users there are many applications in which setting the focus automatically in a field just makes a lot of sense.

But, as should be noted by my word choice, there is also an asymmetry to the damage accessibility considerations or lack thereof can cause - in disabled users they can make the site unusable, in non-disabled users they can make the site slightly annoying.

It would seem browsers would benefit from an easily-toggleable "disable auto-focus" option. That seems like a win/win to me

> One particular thing is that it is generally recommended against auto focusing in fields [...]

What do you mean by "generally recommended"? The publication reviews WCAG 2.0. I don't know any WCAG recommendation that fits your described annoyance. In fact, WCAG 2.1 does recommend to e.g. put focus on the first form element with failing form validation, see https://www.w3.org/WAI/tutorials/forms/notifications/#after-...

More information: https://www.w3.org/WAI/WCAG21/Understanding/on-focus.html

actually I was going quite fast when I wrote it, and I wrote auto focus when what I was trying to convey is step 3 of the intent - focus is changed to another component when that component receives focus;

If for example you have an application for finding service errors in an area you might show a form when people first enter the application, search for address, users search and select the address the form goes away and shows results (this right there would be an accessibility error although quite reasonable for a non-disabled user) at the top of results there is a change address button, clicking that brings the search form back into view and sets the focus in the search field.

The loss of context with that operation could be a real problem for a blind user (there are of course lots of forms of visual disability, so I will in this case specify it is blindness that is most seriously bothered by this common functionality that benefits sighted users, but at any rate I have interacted with some applications that did this which navigating blind was an irritant and navigating with sight a benefit)

So what I mean by generally recommended is - don't do things like my scenario above which violate point 3 https://www.w3.org/WAI/WCAG21/Understanding/on-focus.html even though that behavior is a minor benefit for the sighted user with no disability, and in the case of a sighted user with motor disabilities probably a real benefit.

when I say (this right there would be an accessibility error although quite reasonable for a non-disabled user) obviously that means that it would be unless you did something to let people know the form went away and next you will be reading service errors related to the address you searched for

I just published a post in the same vein: The Best Accessibility Features You've Never Heard Of. [1] I describe several examples of super helpful features that most people don't even know exist.

1: https://beelinereader.medium.com/the-best-accessibility-feat...

What is accessibility, exactly?

I think the name says a lot: access ability.

To me, it means allowing to access.

There is no word disability anywhere in there. It has nothing to do with disability.

It is about thinking ahead about different scenarios and situations you users could find themselves in and trying to address them.

Is a slow or unreliable connection an accessibility issue?

Well, does it prevent someone from accessing your service?

What if someone has an older browser and has no control over it, unable to upgrade either the device or the software?

Will your service refuse service to them?

Vision impaired and such "extreme" accessibility challenges are only the tip of the iceberg, and I think most Web developers today are hiding their head in the sand, creating a rather rude experience for all except those privileged enough to be both physically able and not situationally impaired.

Accessibility is about much more than aria tags. When done well it is a holistic approach that benefits any user. It really shines when included in the design process because it can depend on how information is organized. Having a rational flow to the sections of content pages helps anyone. For example, modals are often a cheat to escape good content design. Also, every site that I have made an effort to implement accessibility had SEO benefits.

At the university, no less, I could never get my web accessibility push validated by anyone. It was awful.

Finally, I flipped the script. Making something more accessible generally gives it more SEO juice, in my experience (such as it was back then), and I could always sell people on that.

My understanding was that skipping accessibility features was more about cost than anything else.

Cost, knowledge deficit of the designer &/or eng side, inertia.. there are a lot of reasons. Many html a11y features are as easy to implement as adding an attribute (but people are unaware) -- other things, like designing a product flow to be accessible, can't be fixed with engineering; they have to be redesigned.

My team at LinkedIn is trying to solve the eng side of this with a combination of automated tooling like linting & headless testing, reporting, etc., trying to make it as painless as possible for an engineer to fall into a pit of success re: a11y for web/mobile experiences.

Not cost of implementation, I don't think. Maybe cost of "lost value of data and advertising they could collect".

Do you think it's more expensive to implement a few accessibility features their site had with little effort in the 90s, or to fight a case to the Supreme Court, as in the case of Domino's?

https://news.ycombinator.com/item?id=21188092

I doubt it would go to court the vast majority of the time, even for public facing sites, but especially not for internal facing.

But did it improve the click-through rate?

Can’t access the article but IMO websites with low accessibility often have major usability issues, e.g. can use without a mouse, non-focusable buttons, wrong form elements, validation errors with pop-ups, forms get stuck in weird states, scrolling has annoying side-effects, etc.

If that is the case I wouldn’t be surprised if churn rate was negatively correlated with accessibility.

Yes, of course.

Get them to install Vimium extension and a Tilling Windows Manager.

This doesn't seem to address the point of the article, which is the (in)validity of the argument "I don't need to/shouldn't implement guidelines that help users with disabilities, because they are ineffective for/hurt users without disabilities." Proposing something else that disabled people can do (I guess that's who 'them' is?) is probably not helpful here, although it could be helpful in a thread looking for tips for disabled users.

> Proposing something else that disabled people can do (I guess that's who 'them' is?)

I would guess that 'them' refers to nondisabled users, who are the only group mentioned in the headline.

> I would guess that 'them' refers to nondisabled users, who are the only group mentioned in the headline.

That's certainly a logical reading, but I have even more trouble interpreting the post that way (but this ambiguity of interpretation is one more reason why drive-by comments—not yours, but the earlier one to which I was responding—are less than helpful). The question isn't whether there's any way to make browsing easier for non-disabled users; it's whether making browsing easier for disabled users makes it harder for non-disabled users (and the answer is no). In that context, it's not clear why one would want to provide advice about the browsing habits of non-disabled users.

As I read it, the question is "do accessibility efforts do anything to help non-disabled users?", and the implied message of the response was "if the non-disabled users switch to vimium and a tiling window manager, then yes [but otherwise probably not]".

I use vimium because of my disability, actually. I can say the flags when my eye tracker isn't cooperating.

..but you know what helps more? big buttons I can click with the eye tracker! not hidden in modals that vanish when I move the mouse away!

Sorry.... I'm not a native speaker. My initial thoughts in the post was about why bother? Vimium and TWM is intended to non-disabled people and I used to use Acceptability to avoid mouse before discovering Vimium. So, it's a fact which Web Acceptability is good to non-disabled, but why push it when Vimium solve it? Anyways, as the first guy replied, although Vimium helps, it lacks.

Reply on news.ycombinator.com