Implementing Web accessibility guidelines for nondisabled users (2016)

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.<p>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.<p>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.<p>But then again, web accessibility is what I do for a living, so of course I’m a bit biased. :)

Facebook&#x27;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.<p>I&#x27;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])<p>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).<p>1: <a href="https:&#x2F;&#x2F;unreasonable.is&#x2F;how-to-stop-working-and-be-more-productive&#x2F;" rel="nofollow">https:&#x2F;&#x2F;unreasonable.is&#x2F;how-to-stop-working-and-be-more-prod...</a>

Unless I&#x27;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.

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.<p>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.<p>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.

I just published a post in the same vein: The Best Accessibility Features You&#x27;ve Never Heard Of. [1] I describe several examples of super helpful features that most people don&#x27;t even know exist.<p>1: <a href="https:&#x2F;&#x2F;beelinereader.medium.com&#x2F;the-best-accessibility-features-youve-never-heard-of-94ebc81320ee" rel="nofollow">https:&#x2F;&#x2F;beelinereader.medium.com&#x2F;the-best-accessibility-feat...</a>

What is accessibility, exactly?<p>I think the name says a lot: access ability.<p>To me, it means allowing to access.<p>There is no word disability anywhere in there. It has nothing to do with disability.<p>It is about thinking ahead about different scenarios and situations you users could find themselves in and trying to address them.<p>Is a slow or unreliable connection an accessibility issue?<p>Well, does it prevent someone from accessing your service?<p>What if someone has an older browser and has no control over it, unable to upgrade either the device or the software?<p>Will your service refuse service to them?<p>Vision impaired and such &quot;extreme&quot; 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.<p>Finally, I flipped the script. Making something more accessible <i>generally</i> gives it more SEO juice, in my experience (such as it was back then), and I could always sell people on <i>that</i>.

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

But did it improve the click-through rate?

Yes, of course.

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