WebA11y

The tabIndex attribute can be used to allow nearly any element to be put into the tab order or receive focus programmatically. This has been implemented in Internet Explorer starting with version 5, Firefox starting with version 1.5 and is currently being implemented in Opera 9.5.

Being able to set focus to any element on the page is important for accessibility in order to implement full keyboard navigation. Elements that represent the intial interaction with a user interface component

can be but into the tab order. Other elements which are part of a particular user interface component can be interacted with via other key combinations. The keystroke interaction and identification of the user interface components to assistive technologies depends upon being able to set focus to these elements.

How Focus and tab key navigation work

• Normally only input and anchor elements are put into the tab order of a page by default.
• Setting a tabIndex attribute of 0 onto an element will put it into the tab order of the page and allow it to receive focus via the keyboard.
• Setting a tabIndex of -1 on an element will allow the element to receive focus programmatically. For input and anchor elements, setting tabIndex of -1 will remove the element from the tab order and allow focus to only be set programmatically.
• Setting a tabIndex of >0 onto an element will put that element sequentially into the tab order based on the tabIndex value. Elements with a positive tab index are put into

  the tab order before other elements with a tabIndex of 0 or which are in the tab order by default.

There are different behaviors for the tabIndex attribute and capitalization of the I makes a difference in how the attribute is interpretted in html and xhtml.

After testing different combinations of setting and querying the tabindex attribute, a set of best practices is outlined below followed by a table listing the results of each test.

Using tabIndex across browser and content type

1. Always use tabindex with lowercase i in markup. See row 1 in table below.
2. Use tabIndex with uppercase I when setting in script via element.tabIndex. See row 4 in table below.
3. Check browser and/or content-type when setting in script via element.setAttribute()
   • if is IE or content-type is text/html - set via elem.setAttribute(tabIndex) uppercase. See row 6 in table below.
   • if is content-type application/xhtml+xml or not IE 6 or 7 - set via elem.setAttribute(tabindex) lowercase. See row 7 in table below
4. Use lowercase when querying a value using getAttribute(tabindex) that was set in markup as lowercase. See row 9 in table below.
5. Use lowercase when querying a value using getAttribute(tabindex) that was set directly on element using element.tabIndex uppercase. See row 15 in table below.

   Setting tabIndex directly on the element using element.tabIndex avoids having to check browser or content type when getting the value.

6. If the rules above have been followed, use lowercase when querying a value using hasAttribute(tabindex) where available. See rows 25, 31 and 33 in table below.

Simplified Rules

• use tabindex lowercase to set in markup
• use element.tabIndex with uppercase I to set in script
• query via getAttribute(tabindex) lowercase

TabIndex testing results

The following table shows the results of testing on Windows with Internet Explorer versions 6 and 7, Firefox 2, Firefox 3 (3.0a9pre dated 2007/09/27) and Opera 9.5 alpha (build 9500 dated 2007/09/04).

IE 6 and 7 where tested using HTML 4.01 strict and transitional. Firefox 2 and 3 as well as Opera were tested with HTML 4.01 strict and transitional as well as with XHTML 1.0 strict

served with content-type of application/xhtml+xml. Unless otherwise noted, a div was used as the test element.

Table Notes:

1. Setting in markup as uppercase tabIndex does not work in XHTML to allow focus to element.
2. setAttribute(tabindex) lowercase does not work in IE to allow focus to element.
3. setAttribute(tabIndex) uppercase does not work in XHTML to allow focus to element.

• Test file for HTML 4 strict
• Test file for XHTML 1 strict

Here are some accessibility demos of Dojo that I recorded so show keyboard, low vision, and screen reader support in the Dojo widget set. These were created using a Dojo 0.9+ version of the widgets so accessibility wasn’t fully complete. The Dojo 1.0 core widget set will have accessibility completed.

• Dojo Keyboard Demo
• Dojo High Contrast Demo
• Dojo Screen Reader Demo

Since I work in accessibility, these recorded demos shouldbe captioned. Unfortunately I don’t have the time or resources to complete the captioning right now. So, in order to make them available I am posting without the captioning and will work on that in the future.

Sites like csszengarden.com prove the power of CSS, but to mere mortals like myself it can still be pretty daunting to get CSS layout right. I consider myself a competent programmer. I have programmed in PC assembly, C, C++, Java and the languages of the Web but CSS still daunts me. And I have to believe that I am not alone.

Working on Dojo recently I needed to create a layout that consisted or an outer element that contained an input element followed by a sometimes displayed error icon implemented as a background-image. Being a good accessibility person, my goal was not to use a table for layout but to use the power of CSS. Suddenly I was transformed into a complete newbie! It took me many hours to get the proper combination of divs, spans and proper CSS to get the block layout to work. Then add in the fact that none of the browsers implement CSS in the same manner and it became a lesson in frustration! Luckily some of the other Dojo folks were able to offer suggestions and I actually got it to work. I am still amazed at the tricks and suggestions that folks had to offer. I have to believe (for my own self respect) that this level of knowledge comes from working with CSS on a regular basis and that I am not missing some important “CSS gene”.

But, I have to believe that I am not alone in my level of frustration with CSS and that is why so many people continue to use tables for layout. Tables just work and they don’t require odd permutations of display:block and spans inside of divs that have width and height specified. And, in the end I ended up using a table so that I could guarantee that the icon would never wrap to a new line.

So what does this rant have to do with accessibility? Well, most accessibility tomes encourage the use of CSS. Certainly that is easily accomplished to specify font faces, sizes, and colors - hey, even I am competent at that! I have to give the WCAG folks (of which I was once an active participant) credit for not outlawing the use of tables for layout. Tables are easy, they work across browsers, and assistive technologies deal with them fairly well. Someone needs to make CSS accessible (pun intended) to the masses. The Web took off because nearly anyone could master the basics of HTML to create a Web page. WYSIWYG development environments such as Front Page and Dreamweaver and others made it even easier to create pages quickly (no comment on the robustness of the HTML generated - it gets the job done). But, until CSS is implemented consistently across the browser and there are development environments that can generate the appropriate CSS it will remain a voodoo science for experienced Web developers. I guess that guarantees job security for Web designers and gurus - and the continued use of tables for layouts by the rest of us. Sad but true. I wish I had a solution - I’m hoping that someday someone will uncover the secrets and create a tool to help the folks like me use CSS to its full potential. Or maybe the CSS specification will be comprehensible by mortals - hey, I can dream!

There, I’ve ranted a bit. I feel better, but the problem remains. CSS is just too hard, complicated, and poorly implemented across browsers to be used by the masses. sigh

I learned long ago that the secret to traveling for work as a software developer is to give presentations at conferences. Thus, I learned to be comfortable giving presentations in order to present at conferences and “see the world”. I travel from 4-8 times a year and that is an amount that allows it to remain exciting (most of the time) rather than becoming a drain. When I started working on Web accessibility there were likely to be people of varying abilities in my presentations so I learned to make my presentations more accessible to all attendees. Recently it occurred to me that these additional techniques are important for all presentations.

There are many disabilities that are not immediately obvious. There are different cognitive disabilities and almost everyone has a preference for either visual or auditory learning. Some visual disabilities are obvious but other may not be, and hearing impairments can’t always be detected. And in any presentation room there is likely to be some person who can’t visually see the screen well or hear the presenter. This could be due to the large person sitting in front of him, or the person chatting on a cell phone or with the person next to them. The placement of the podium or other physical structure, reflections from a window or light source, or proximity to a moveable partion wall all could create additional visual and hearing difficulties.

So, I have come up with Becka11y’s 4 Basic Presentation Rules to make all presentations accessible to all.

1. Present the information as if the audience cannot see the screen
2. Create presentation slides that assume the audience may not hear all of your “words of wisdom”
3. Keep bullets short and to the point.
4. Repeat and Summarize

For those of you willing to read a bit further, here are the details.

Present the information as if the audience cannot see the screen. Verbally explain any important pictures, charts and graphs. When describing a line chart it is not enough to say, “As you can see the red line shows the increasing trend in the use of JavaScript.” Instead say, “The red line shows the increase in the use of JavaScript from 20% to over 50% from 2001 to 2007.” That doesn’t really take that much extra time and it ensures that all members of the audience are getting the same information. I think people sometimes feel awkward explaining information that is visually evident on the screen but remember not everyone may be able to see the screen and they are probably not as familiar with the material as you are. Providing the information in different modalities is critical to getting your point comprehended.

Create presentation slides that assume the audience may not hear all of your “words of wisdom”. Don’t skimp on the details. Make sure to include the legend and numbers in the chart. If the person can’t hear you explain the details, hopefully he is sitting where he can see them on your charts or can review them later from the handouts or presentation file.

Keep bullets short and to the point. This may seem to conflict with number 2 but in my opinion too much textual information on a slide is as bad as too little. Cover the key points in the bullets but don’t overwhelm. Know what you want to say and write it as simply as possible. You want the audience listening to you, not reading a novel in your charts. The text on the slide should cover the key information you want the audience to take away – you fill in the details while presenting.

Repeat and Summarize – remind people why they came to see you in the first place! Sometimes if feels awkward to say the same thing twice but if you word it a bit differently you will ensure people understand your point. Someone who missed it the first time around will “get it” (and hopefully retain the information) when it is repeated. If a person missed something during you talk due to distraction a review of the highlights and the key message will make certain she walks away with the message you want.

These points aren’t anything new and you’ve probably heard them before. Next time you go to a conference see how well the presenter stacks up. Hey, if you see me present, let me know how I did! And, next time you present keep this in mind. Its not just about accessibility it is about reaching the entire audience, making the presentation worthwhile for all, and getting your message across. Now, if I could only write as succinctly as I think I can create bullet points this post would be much shorter!

Here is another theft from my Dojo work - Adventures in Accessibility - What is a screen reader?. This is even more of a cheat since this post refers to the video of a presentation given by Doug Geoffray about the Window-Eyes screen reader. The presentation covers screen reader basics as well as technical details. Well worth the time if you haven’t experienced a screen reader.

I work on accessibility of the widget set of the Dojo Toolkit. I created a post explaining high contrast mode on the Dojo site and I’m going to cheat and reference it here as well. I guess that is one way to get some content started!

Widgets and High Contrast Mode

Just getting started - more to come……