IPad with a keyboard

After I learned how to type on a mechanical typewriter about 20 years ago and then on a computer some time later, I never thought I'll have to figure out how to do something as basic as hitting "enter" or "return" on a keyboard again. ...and least of all did I expect this to happen with the king of usability - an apple keyboard and an IPad combination. I am surprised about this so much so that I still think I am missing something. Untill I came across this excellent post about how to use a keyboard with the IPad I was totally unable to use my shiny new apple wireless keyboard with the new IPad to do anything useful.

Someone needs to tell apple that there is an enter key on all keyboards and that is the most obvious way of tapping something on the IPad screen from the keyboard.

Headings

Headings - as the name suggests - are used to highlight or mark text appearing at the top of sections of a document.
I want to bring out how invaluable the simple mark up elements h1 h2 etc. are when it comes to web page accessibility using a keyboard.
Imagine that your Web page has about 40 navigation widgets, links and buttons, (not a very large number considering an average application - a random yahoo mail page that I just viewed has 61 links).
Now imagine that using the keyboard, I need to click the 27th item....oops! the poor tester who was denied the mouse is sure to get carpul tunnel tabbing 27 times on every page (a topic I'll touch again in a later post).
This is only the beginning.
Now grasp the fact that a screen reader usually presents a Web page as if someone was reading the page from top left to bottom right linearly with every navigation widget appearing on a new line.
All those top menu links, those left menu items (and often the drop down menus) appear at the beginning.
The relevant content of the current page starts after this - and it is not even a tab stop.
As a screen reader user, I have no simple way of getting to read this "main" content of the page -- something that is visible to a sighted user as the most prominent thing on the screen is accessible only after wading through all that header and left nav clutter.
Try going to the microsoft Msdn pages. The top and left nav clutter there is hundreds of links - I read those pages from the bottom up to avoid this.

Only if the main content would start with a mark up like a heading.... and most screen reader implementations allow me to move through headings in a page

This very basic usability guideline of marking important sections of the screen with relevant headings is almost universally ignored:
google does it on its main search results page but forgot to do it on all other pages like google scholar search, gmail etc.
yahoo has it in the classic mail view but for some reason forgot to add it to the new and improved yahoo beta.

Do you have headings for identifying parts of the screen in your Web application?
Remember that in addition to their traditional use, these simple tags help users navigate through your app.

Keyboard

I'll start with the most basic requirement for software accessibility for the visually impaired - allow all navigation and functionality through the keyboard.
It is commonly known that blind users use a software called a 'screen reader" that gives them an audio output interface to the computer instead of having to look at the traditional video interface (the screen).

However, there is also a difference in the input interface that blind users use. They use only the keyboard and not the mouse -unless if they have to.
So, if you want to make your software/web sites accessible for the visually impaired, it is not sufficient to just allow screen readers to read the output. It is equally important to allow users to use only
the keyboard for all input and navigation.

This simple usability requirement has a lot of ramifications when it comes to user interface design.
The last time you created those fly out menus on your Web page, did you ever try using them without a mouse?
The last rich client online trading application with a lot of panes for displaying the different parts of your screen. Did you try moving across those panes using the keyboard alone?
The drop down list that posts back the page on selection change. Did you try selecting the third item in that drop down with the keyboard?

The answer to the above and other similar questions is "no" for most applications and Web sites that I've seen - even as a part of the team that was developing it.

For screen reader users, it is essential that they be able to do all input and navigation through the keyboard. And interestingly enough, it is very very simple to test. Simply deny the luxury of a "mouse" to one person in your QA team.
And treat everything that person cannot do as bugs.
this simple test will have you cover over 50% of the accessibility chalenge - the input interface.

Having said that, I need to also add that this simple test may bring out all the accessibility bugs but their solutions may not be simple.
If you're the one trying to get accessibility in, you'll get push back from first the "tester who was denied the mouse", then the user interface designer who designed the screens and navigation flow, the developer who has to do all that "extra work" to implement the new "more complicated" design, the architect who needs to come up with a "new technical solution" for something that developers in his/her team could otherwise do on their own, the project manager who just cannot understand what all this re-work and extra time is all about and so on.

... so, good luck!
The subsequent entries in this blog will deal with specific tips on how to make apps more keyboard friendly.