Accessibility: resurrection of a web developer.

My introduction to Accessibility.

As any other developer in his initial stage, I too started out my programming at college, where there was no one to guide me. I remember writing rhtml(ruby html wrapper) when I did not know what html was.  Later I realized the importance of html. Its been years of web development and it was recently around a year back when I learnt what semantic html is, that changed the developer in me. The guy who was concerned with code quality and web security, realized that he was contributing to bad, html code. With my company’s support, we together worked towards achieving web standards for our app which earned us Level AA certificate and happy customers like NDIS(National Disability Insurance Scheme) Australia who poured out their kind words of appreciation on our work. Today I’m keen on creating accessible prototypes for the front end, spreading awareness across the team and across the community, I’m trying to take my learnings to everyone I can share it with and making them a web standardized developer from yet another web developer.

What steps need to be taken towards these goals ?

  • Spread awareness and learning among Web developers
  • Make companies insist their developers write better and accessible web/apps. And follow web standards.
  • Motivate more developers into accessibility and need for that.

Thanks Nikhil, for proof reading this article.

Tabindex, using it right is all about not using it.

We know, tabindex exists for a purpose. But it has its own use. Like every other thing, we tend to over/mis-use tabindex as well. Today the Web has changed, and there are better approaches to handle the use cases that tabindex used to in the past.

I would say that the only place where using tabindex is legitimate is when using −1 as value. −1 is used to make an otherwise not tabbable element tabbable. Best use case for tabindex −1 is for skip_to_links. A skip_to_link is made by setting the href as the id/name of the receiver element. And the element has to have a tabindex −1 to receive the tab. Elements like link(anchor), input fields(form controls) are designed to receive keyboard tab. And for elements that cannot receive tab, we use this method to make it tabbable.
Link:

<a href="#conta11y" id="jmp2Cont"
    onclick="jQuery('.cont').focus()"
    title="Jump to Content">Jump to Content</a>
Land at:

<a href="" id="conta11y" tabindex="-1" title=""></a>
For everything else tabindex is evil.
You can use skip-to links, but html5 has come with semantic elements like <header> and <footer>. Assistive Technology (AT) understands these objects as landmarks and provided option to jump to them directly. This way also helps user to jump to content easily as soon as the page loads, than having to navigate through many navbar links to reach the main content.
ARIA (Accessible Rich Internet Applications Suite) can be used for the same. If role=“main” is added, AT will understand  that this is the most important part of the page.
So, now we have an alternative for skip-to links as well. Let’s not use Tabindex.
The bad sides of using Tabindex are listed below. They are about development practices and code quality.
  • Code becomes hard to maintain.
  • For minor additions, we will have to do extensive tabindex changes, like adding tabindex values towards the next tabbable elements.
  • We are achieving some functionality by addition of a new attribute tabindex, when we can achieve the same by (probably) reducing the number of unwanted HTML elements (like excess DIVs used) and by using proper HTML semantics.
The HTML itself has to be constructed in such a way that it is semantically meaningful.
The best way to make sure the HTML we wrote is semantic, is to represent it as a tree. Then see which all elements are placed at what level in the tree. If the order in the tree is not even, then it is a sign that our HTML is not semantically correct.
This also helps to reduce unwanted HTML elements. We tend to write a lot of DIVs only to use with CSS. This is a smell. We should reduce the DIVs and utilize CSS to the maximum to layout the page as we want.
Use proper elements like UL-LI, H1, H2, H3, P etc to define content, instead of using DIVs.
There are cases where people uses DIVs for lists. Certain plugins also do the same, making things out of the way.
There are people who write a lot of DIVs to show a list of buttons. Say, for showing a list of tabs, navigations etc. The only proper way to display it is to show it in UL-LI lists or OL-LI as required. Even people who use LI, add a DIV within the LI, which is an overloaded use of div.
</pre>
</div>
<div>
<pre><ul>
  <li>
    <div>Wrong way of doing it!</div>
  </li>
</ul>
We don’t need an extra DIV there. If we need to add any styles, we can add it on the LI itself. Just make sure you select the element using a class name, than using the element itself, in the style sheet.
CODE:
</pre>
</div>
<div>
<pre><li class=“list”>Content</li>

<style type=“text/stylesheet”>
  .list { color: blue; }
</style>
is preferred over
</div>
<div>
<pre><style type=“text/stylesheet”>
  li.list { color: blue; }
</style>
This makes the code independent of elements and a change at a later point becomes easier. As an Accessibility POC for my company, I prefer this approach as that makes my job of making the elements HTML standards compliant easier. This method reduces my job, at least at the CSS level as fewer things are prone to break in this approach.

Thoughts ?

Thanks to @unnitallman (Unnikrishnan KP) who took out his time to proof read this article.

How many of us Care ? Accessibility A11y

Inspiration to write this blog was through my studies on Accessibility and how disabled people want webpages to be delivered for better understanding and interaction.

That’s when I got a lot of points that we could use to improve the accessibility experience in our applications. I am using Facebook as an example for explaining some real world situations people experience. Many of them, Facebook is/was facing at one or other point.

I’m jotting down some of them here with solutions for some as per guidelines.

  • Much talk is there about having accessible images. Giving image element alt attribute. using aria-labelledby and aria-describedby to make it much presentable, using role as presentation. But from the users posts, it looked like they where not much concerned about images or their labels. Couple of things we need to think about are.
    • Their audience and whom they follow where unique. they also posts the content in a fashion very much accessible to users. Mostly Text updates, status messages etc.
    • While a normal user, when he uploads an image, he doesn’t bother to make the image accessible by giving an explanatory label/caption, or a descriptive definition of image as image description. Worst case, they put in puzzles as image caption, which will not hold a direct relation/ explanation with the image.
    • Suggestions from users, was to avoid pictures from timeline, or at least give an option to hide all pictures with a link.
    • It is a good thing to understand how these users would prefer the content to be and provide additional controls.
    • If a control like hide all photo statuses is irrelevant for a normal user, then providing it offscreen is a wonderful feature to add for ATusers(one who uses Assistive Technology).
    • So they don’t want to interact with photo’s at all.
    • Similarly they would want to remove all games and ads(advertisements), because games are totally inaccessible and ads clutter up things so you can’t find what you really want to find like a text status post – UX
    • Well when it comes to Ads, Its your call. However is there any point of disturbing AT’s (Assistive Technologies). with ads that will not be read out properly to these users ? – in that case aria-hidden is what you want to have to save these souls.
    • In terms of look and feel of the app, they are okay with fair bit of changes in the way the app would behave otherwise, to adapt to their needs. All what matters is semantical meaning that is conveyed by the page, overall.
  • Another common issue raised would be “The feature did exist earlier, but was moved later with update to new layout.
    • Moving around stuffs every now and then confuses people with perfect vision. For people who rely on placement of things on the page, shifting things is like playing Hot Cold Game.
    • So please provide easy access to info and config of the object (Object here is any part of the page that has a logical explanation of itself)
    • Do not change the layout pretty often. An ATuser will find it hard and will feel lost.
  • Another issue would be, if all devices doesn’t represent data in a same format.
    • example issue: lack of chronological order in mobile, while computer follows that.
    • People do expect a relation between the behavior of an app in computer and mobile, or any other device. Again the placement, order, and similar logical organization is crucial. For them whether its a computer, mobile or anything else, its all representation of a same set of data.
  • People uses ATs like Dolphin Guide, Jaws, Braille-notes, Dragon NaturallySpeaking, System Access, Window-Eyes, NVDA, Voice Over and more.
    • Its a difficult task to get it right across all of these. But doing it is the only way to get your site accessible. If you hold a huge user base.
  • Provide a Special feedback form for Special Users. https://www.facebook.com/help/contact/169372943117927
    • This one, FB has got it perfect. Its highly customized and made easy for an ATuser to submit a grievance. But still remember, they might not even be able to understand what is happening, other than something is wrong.
  • Understand that an ATuser wouldnot understand what went wrong. Say a comment posted with just an Emoticon in it, and a like button. A user will be wondering what that like button is there for, if the emoticon doesn’t have an alt text or is not read. He wouldn’t even understand that he is in a comment object.

Some basic tips while coding…

  • Every thing that is a list of lists(not just ul-li lists, list here is semantically list), should be made as a tree. With option to skip from list to list. Each list should be provided with proper explanatory label. Don’t forget about I18n, while adding label.
  • usage of Headers should be done properly. Headers should be nested properly.
    • Headers with an improper level, when the Html elements are represented in a tree structure, is a smell.
    • <div>
      
      <div>
      
      <h1><!— third level —></h1>
      
      </div>
      
      <h2><!— second level —></h2>
      
      </div>
      
      
    • is considered to be wrong implementation.
    • AT’s have their own ways to navigate through Headers. So even if you miss to give ‘skip to content’ links, proper Headers will serve the best. Even better that ‘skip to content’ links.
    • eg:  in JAWS, press H to navigate to the next heading
  • By this, what I want to superimpose is the truth that making a site Level AA by an audit is not exactly all, when it comes to accessibility.
  • The scope is way too more, to achieve. And achieving it correct comes with an add-on advantage of easy keyboard access to the site.

Now to Panic, Target Corporation was charged $6 Million as penalty for not being accessible http://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corporation

 

These are just some of them. WIll try to keep this blog updated with things that I learn. Do feel comfortable to disagree, and please be sure to share your opinion. 🙂

References:

https://www.facebook.com/notes/facebook-accessibility/developer-spotlight-a-conversation-with-stefan-parker-user-interface-engineer-at/567184129991983