Category: a11y

As the Americans with Disabilities Act (ADA) turns 25 years old, I am disappointed that the law is still needed to defend the rights of people with disabilities. The ADA author, Robert L. Burgdorf Jr., recently wrote an article for The Washington Post where he stated, “The ADA was a response to an appalling problem: widespread, systemic, inhumane discrimination against people with disabilities.”

Accessibility benefits everyone.

So, with that law in effect, there will always be ramps or elevators to go along with stairs, braille on signage and other features implemented in every newly constructed or remodeled building since then. Meanwhile, if you look carefully, people whom are elderly, on crutches or pushing strollers (or tired or with their arms full or ect) are using the elevators and ramps too?

These solutions exist, and are available to people not labeled disabled, because they were part of the requirements for the design and development process.

Good commercial construction builders know these  requirements are a part of every build, so doorways are large enough, do not have uneven floor seams and so on. With brand new construction sites, you wouldn’t expect to see someone ripping out cemented steps because the stair rise is completely wrong or retrofitting railings because they were not installed. If they were, they should not be building anything. Am I right?

Process changes: Mobile first

Not that long ago, there was a huge challenge given to developers and designers to shoehorn desktop sites into mobile sites. So, what needed to happen was for everyone to think about the mobile design before the desktop design because trying to cram the bloated desktop content into the mobile site wasn’t working. We flipped the design/development process, as we knew it, on its head and now we start with the mobile version.

Let’s hit the reset again!

Trying to retrofit accessibility into a website that never had it is very challenging. Rewriting spans that should have been buttons (or worse, links) and fixing many other common faux pas’ can take a lot of time and resources. The way I’ve been doing it, quietly baking it into each project I’m working on. If we are redesigning the homepage, I make sure the homepage comes out accessible (or the best I can do at the time…I’m still learning).

Wouldn’t it be great if, like a new construction site, we started with accessibility as a normal part of design requirements? And, wouldn’t it be so much easier if we worked from with accessible frameworks? If you know of any that are 100% accessible, please let me know. I am putting my money where my mouth is and giving back by working on the accessibility of open source projects I use (e.g. WordPress).

As we make web content more accessible, it benefits everyone because it makes it more usable: easier to read, use and understand. I see it as an opportunity to create better user experiences for everyone regardless of ability.

I wish we didn’t need laws (or lawsuits) to force accessibility. But, because of the ADA law, we do not expect to hire a construction company just for accessibility features. You just hire a construction company and they should follow the building code laws. The same should apply to the web. Just developers or designers following the web standards, accessibility implied.  Someday. 🙂

Shoot, we still say responsive web design. Isn’t just web design, at this point?

Almost a year ago, I attended JSConf. It was amazing. I left that conference with SO many great takeaways, the biggest and most challenging for me was web accessibility.

For a few days following the event, I kept finding myself thinking more and more about how users that were blind, visually impaired, deaf, motor-impaired and so on would use the thing that I was working on. I was visualizing these people in my head struggling over the the most basic aspects, and suddenly it became real for me. I could see how bad the user experience was and I wanted to fix it ASAP!

But, where should I start? So, I turned to the internets and sought out to find the go to resources for web accessibility.

Step 1.: Audit the site

1. W3C validate (this will help you fix heading errors, ect)
2. Navigate the site strictly via tab. Can you tab logically and easily? If not, note where/how/why to fix.
3. Automated tests. (ATs)
   • I use gulp, so lean towards using gulp-a11y (free)
   • There’s also tenon.io ($$)
   • I like running updated pages through WAVE. It’s not automated, but, I find the info regarding the errors helpful.
4. Repeat 1-3 until no more errors. Seriously, do not pass ‘GO,’ do not collect $200. Do not move forward until your site passes these tests.

Some of my gotchas that made it to production for a sprint (or few):

• The first rule of aria… – It seems as though #a11y newbies (me included) get aria-happy, the ATs will help catch errors here. Another good article on aria: HTML5 Accessibility Chops: notes on using ARIA.
• Just because you have alt tags, doesn’t mean they are good ones. I had issues with alt text being the same as the text below the image. Sometimes it is ‘ok’ to have alt=” “. ATs will point this out too.
• Out of order headings h1, h2, h4 … but no h3. 🙁

.: Knowing Where To Go For Help/Info

Information

• WebAIM
• A11Y Project
  • Checklist
• The Paciello Group
• Web Accessibility Course by Google
• Karl Groves‘ website
• ARIA Examples by @heydonworks
• Census Info (helpful when trying offer data/statistics on the population impacted by accessibility needs)

Social

• Twitter: #a11y
• Slack
• Accessibility Wins on tumbler – a curated list of sites implementing specific features for accessibility

Testing

• Wave
• gulp-a11y
• Tenon
• How to: Voiceover
• Developer tools in chrome and FF
• Google’s Complete List of Accessibility Tools
• Toolbar for IE 9+
• Screen Readers
  • JAWS for Windows (free 40 min. demo version)
  • NVDA for Windows (free)

Frameworks

• Bootstrap
  • Assets Framework by the government based on bootstrap
  • Paypal
• Angular
• WordPress: themes | plugins | group
• iCheck: Accessible checkboxes and radio buttons using jQuery

Transcriptions

• Verbalink
• Speechpad
• Rev

Some history behind me writing this post. It took me a year to get to the point where I could say, confidently, I know where to look for good info on this topic.

And, here’s what I’d like to call my “Don’t do what I did” list (a.k.a. – chasing your tail around until you’re dizzy):

1. The w3c – I love you, but I can’t read these docs without a constant drip IV of caffeine and a shock treatment for every time I fall asleep. (Of course I reference the w3c for accuracy, but NOT for how-to’s.) They, also, have a lot of content via the web accessibility initiative, but again…so much content/reading, yet, so few examples.
2. MDN – In fairness, it looks like there have been a lot of updates here. When I was originally here, there were pages that were like… (╯°□°）╯︵ ┻━┻) f-this. No one can agree on best practices and until they do, we are not dealing with documentation. But, it’s still a cluster-mess if all you are trying to do is figure out how/where to get started.
3. Finally – I was like… I just want examples!!! Someone, please, just show me some freaking examples!!! So, I went to see what the frameworks (bootstrap/foundation/ect) did for accessibility. Unfortunately, at the time, I was finding nothing, zero, zilch…However, I did find bootstrap plugins and forked repos that were accessible. I was so frustrated to see that these existed, but they were not being brought back to the main codebase:
   • Assets Framework by the US government
   • Paypal Plugin for the components.

Things on #3’s front are changing, as well, for the better and you now see some basic info in the docs. They even point out their color contrast flaws.

So, I was running into all these issues trying to find a good place to start. Eventually, I found Marcy Sutton’s article on how to audit a site for accessibility. YAY!