How we code (for accessibility)

This post results from the need to validate a personal viewpoint I had related to coding for accessibility.

The Gist

Via Twitter and Survey Monkey, I polled anyone who would give the topic a little attention the following question:

Related to accessibility, how do you code?

There were two answer options. Below are the answers along with the response results:

• (6.25%) In support of current screen reader behavior
• (93.75%) In support of the standards (WCAG, WAI-ARIA, etc.)

With sixteen respondents, this was a quick, down & dirty consensus poll, not scientific research. I selfishly needed quick validation that I was headed in the right direction.

The Survey’s Backstory

I am a front-end web developer. During the past 1.5 years, I have found myself neck-deep in digital accessibility. Accessibility has actually saved my career, as I had fallen into a rut. My work now feel reminiscent of the late 90’s, when we dealt with huge browser non-compliance with standards. It was the period of time when the father of Web Standards, Jeffrey Zeldman, and a team of web leaders changed the way we approached coding for the web; code to standards, not browser nuances. Eventually, the browser makers adapted and began following established standards (well, closer at least). We are, again, faced with a similar situation; this time, adding technical enhancements, such as ARIA, and assistive technologies, such as screen readers, to the mix.

Recently, at my day job, we have been developing accessible coding patterns to be reused throughout the organization. We’ve also partnered with an outside form to assist us with our accessibility program. Along side the advice from this outside partner, I’ve also performed my own research in parallel. And here’s where things became dicey for me.

The topic: buttons versus links.

Throughout my career, I’ve strived to code as semantic as possible. Use header tags for headings, lists for lists, etc. Pretty mundane stuff for most developers, but related to accessibility, it’s foundational. So when the outside partner advised us to not use definition lists for lists of pairs due to incorrect screen reader interpretation, I was taken back. There were so many semantic patterns where definition lists made sense; FAQs, etc. Yet, we took their advice (for the most part).

As we worked on accordion-type patterns, we again were challenged by the partner. “Use links for actionable items. You can use buttons as well, but we suggest using links.” This was counter to all the research I had performed. My research showed that

• Links should be used for navigating to another page; on another page or another location within the same page.
• Buttons should be used to trigger an action; submit a form, run a script, etc.

These semantic use cases made perfect sense to me. And yet, we were guided to do the opposite. The reason given was that it was a better user experience; screen readers switch into forms mode when a button is focused on, or activated. This last nugget of information was what tore at me. As much as I am a strong believer of semantic coding practices, I didn’t want it to be for the sake of a poor user experience.

After much research, certain bites of information resonated with me:

Karl Groves – Links are not buttons. Neither are DIVs and SPANs

• If it navigates, it is a link. Use link markup with a valid hypertext reference
• If it triggers an action, it is a button. Use a BUTTON element

Léonie Watson – WebAim Discussion Thread: Definition Lists and Accessibility (unrelated, yet pertinent to semantic coding)

Changing markup patterns to satisfy the vagaries of specific assistive technologies tends to be a slippery slope.

Joe Dolson – Links vs. Buttons for Focusable, Actionable Items – Modern Accessibility Forum

Be sure to note as well that links used as controls will clutter up lists of links; buttons don’t have that problem.

Dennis Lembree – Proper Use of Buttons and Links

When developing a website, ensure buttons are coded as buttons (the button or input element) and links are coded as links (the anchor element).

So with the debate, the research and plain ‘ol semantic markup, a button wins out over a link.

Interesting Survey Comments

As part of the survey, I also provided the means to provide comments or further insight into the selected option.

Trying to code for current screenreader behaviour is like trying to make browsers render a page the same all the time. Unless a major bug needs to be worked around, code to standards. I also acknowledge standards are not perfect. But they address more than screenreader and we should never forget accessibility is more than just screenreaders.

This response falls in line with what I’ve researched and my direction.

If you only code for screen readers, you’re excluding every other disability (including low vision). Terrible question.

I was taken back by this response. However, I was able to take a step back and realize that the responder did not actually have the back story. However, I still am unable to decipher how I communicated “only code for screen reader.” I have heard a lot of concern that developers coding for accessibility focus only on the screen reader. While that may be the case (to some degree), the industry also has to realize that besides being assistive technology for people with disabilities, a screen reader is also a testing tool for developers, to test their code, their development work. Besides browser accessibility toolbars, JavaScript Bookmarklets and automated testing tools, screen readers are the most popular testing tool. And while this development testing is no replacement for screen reader testing by an expert, even a person with a disability, it is necessary.

With regards to coding for low vision (i.e. color contrast, font size (increased to 200%), etc.), for the most part, low vision issues are handle by design, with coders implementing those design.

I welcome your thoughts on my thoughts, and any feedback that would aid my learning and insight into accessibility.