WebA11y

As promised, here are the notes I made in preparation for my Inclusive Mobility Core Conversation at SXSWi 2011. I didn’t need to rely on these too much as people actively participated and asked questions!

General:
Talk is about making mobile applications accessible for ALL. Don’t want to just talk about people with disabilities because all people want to be able to use mobile devices in all environments. PWD are on the cutting edge and we should listen and learn from them.

Poll audience:
Who is aware of accessibility Api for iOS?
Who has used it?
Who has tried VoiceOver on iOS device (3GS and above)?
Any PWD here that use an mobile device?
Which one?
What do you like/dislike about it?
What advice do you want to give developers for making more usable apps?

Where are we with the different devices?

Android

EyesFreeAndroid - Google solution
TalkBack(screen reader), SoundBack(auditory), KickBack (haptic)
Code Factory - just released new set of 10 apps and a screen reader
IDEAL Group - makes accessible open source apps for Android.
Speaking Pad - one of most popular applications. Type something in and press a button for phone to speak the text.
Does Android have an advantage with at least some “hard” navigation buttons? Or devices with “real” keyboards?
Edwin speech recognition app- how useful is this? Is there speech reco built into Android, now?

BlackBerry
no built in screen reader? Can buy one but is expensive

iOS

VoiceOver
Accessibility API
API helps to make apps accessible - what about mobile Web sites?
Voice control - do people use it?

Standards for Accessibility
What about ARIA? HTML 5 is incorporating ARIA so that should help make it more universal and force better support
Use standard HTML accessibility, avoid scripted controls (for now)

Google Voice
How many use it? Still relies on visual interpretation but does provide easier access then typing
Experience on iOS vs Android?

Dragon Nuance Mobile Development Kit
cloud based speech to text and text to speech service that can be accessed from iPhone and Android devices
http://dragonmobile.nuancemobiledeveloper.com/ - developer kit that allows you to integrate into apps

What about captioning?
Google has beta auto-captioning on youTube - but that option is not available on iPad?
auto transcribing could allow you to follow a meeting in a noisy environment - subway, bus, conference, etc.

Self Voicing Apps? What is available how are they used?

What about using the cloud?
Access an assistive technology by sending data to via the network and have spoken text or perhaps a transcript come back?

Need for device independent interactions and events.

Lenovo has eye tracking laptop - do we see that going to mobile devices? Maybe for tablets???

Can’t even remember the last time I posted……. but this seemed like the easiest way to share my thoughts on SXSW this year.

I decided not to lug my laptop around the conference this year and just bring my iPad. I have penultimate for taking notes and can check email, my SXSW schedule and twitter as needed. Only issue with penultimate is I wish I could have a finer point on the stylus - and better handwriting!

Things got started at 2:00 and I attended the interview with Tim O’Reilly. Although he is an icon in the industry I didn’t really know much about him. He started by writing computer books when he couldn’t get a job out of college with a degree in Greek and Latin! I liked this quote that his success has been, “happy accidents that came from ignorance”. He also discussed how great brands have a core - they mean something.

When asked about getting into politics, Tim made it clear that he is working on government and not politics. He said a concept that got him interested in government was in a book that referred to government as a vending machine. Tim’s take on that (which differed from the author’s intent) was the government is a vending machine where you put $ in and get services out. And, it really isn’t working and he believes that government should really work more like a platform. When asked about his political views, Tim believes he is a fiscal republican and social democrat (I know a few people like that ;). He mentioned codeforamerica.org and how govt. needs help from savvy tech folks.

Tim said much more - he never seems to be at a loss for words! That’s what I took away.

I also attended Thin is In The Future of Digital Wallets. This talk reviewed what a “digital wallet” is and who are the players. The presenter, Christina Nguyen White of SapientNitro, indicated that the talk was not technical but more about dealing with the digital wallet from the eyes of the consumer. The four pieces of a digital wallet are

• payment method
• financial method
• coupons
• tickets/passes
• comparison shopping

Examples of players who are “close” in the digital wallet market in the US are PayPal and Starbucks. The big question to ask with digital wallets is security. A poll of who users believe is responsible for security reveals 55% individual, 15% phone manufacturer, 30% carrier responsibility. Who are the players? Consumer, retailer, financial institution, and carrier. Who owns the digital wallet? - financial institution, retailer, carrier. I’m not sure I really want the carrier that involved in my digital wallet but it seems fairly inevitable. Christina spent time discussing the different responsibilities of each of the players. Most of it was all common sense, the retailer needs to build brand loyalty using special offers, coupons, push notifications, etc. without annoying the customer. I was hoping for a more technical talk on how digital wallets will be implemented. My take away is that there is still an opportunity to shape the market with a payment solution using smartphones. ISIS, the mobile payment service organized by the carriers, was offered up as the driving factor going forward in the US but no details were provided.

My last session of the day, How Farmers Get Serious Business Done with Mobile, was a panel of 5 people all involved in the Farming industry in the US midwest. Folks were from Loud Out Technologies, John Deere, Lava Row, agriculture.com. Farmers use of smart phones is 33% Blackberry, 18% Android, 10% iOS. Why is iOS so low for farmers? One reason is lack of AT&T coverage another is emotional - farmers don’t seem to like Apple. It was also suggested that the iPhone isn’t “tough enough” for farm use.

What are the things farmers want in a smartphone? Calilng, advertisement related info, pictures, and 69% use SMS. They definitely use it for data on commodity markets as well as weather. Use for controlling equipment such as sprinklers. During the talk animal management came up as an area with little software - there are no good applications for animal management on the desktop nor for mobile. Looks like a possible market given more stringent livestock controls and tracking requirements.

Talked about needing apps to help with information management. John Deere representative showed a video on Farm Insight. The John Deere service rep appears at a farmers work shed with a new air filter. The tractor was being used out in the field and it communicated to John Deere that it needed a new filter. The farmer contacted the operator and sure enough, the tractor was displaying a signal code for a filter change.

Other resources that came up: farmers4thefuture.com. Farmersfreshmarket.com - there was an article written about this at myfarmlife.com recently.

And got to see my accessibility family at the AIR Awards party! That was fun - it was a fully accessible party with close captioning as well as signing of all the events and music!

Back in November, 2007 I blogged my results of testing the tabindex attribute in several browsers. I recently retested with the latest versions of the browsers and included Safari 4. Luckily the recommended methods for working with the tabindex attribute do not change. Here is the updated version:

All you never wanted to know about tabindex

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, Opera 9.5 and Safari 4.
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, 7, and 8, Firefox 2.0.0.20, Firefox 3.0.1, Firefox 3.5, Opera 9.64 and Safari 4.
IE 6, 7, 8 where tested using HTML 4.01 strict. Firefox 2, 3, 3.5 as well as Opera and Safari were tested with HTML 4.01 strict 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

Once again I was bitten by the manner in which the difference browsers report the value of the disabled attribute. I decided to test the different ways of using the disabled attributes and record my results.

When writing JavaScript I generally use the object.getAttribute("attributeName") syntax to get an attribute value. However, this will return very inconsistent results for the disabled attribute. What makes it even worse, is there is more than one way to specify the disabled attribute on an input element. In HTML 4.01 you should just add the keyword disabled. In XHTML 1.1 you must use disabled="disabled". You can also use this in HTML 4.01.

What I learned from all of my testing is:

• Use disabled (HTML 4.01 only) or disabled=”disabled” (HTML or XHTML) to set in markup.
• When setting via scripting use one of the following to disable and enable, respectively
• inputObj.disabled=true and inputObj.disabled=false via boolean values;
• inputObj.disabled=”disabled” and inputObject.disabled=”" via string values;
• inputObj.setAttribute(”disabled”, “disabled”) and inputObj.removeAttribute(”disabled”)
• When testing for the disabled attribute on an input element, use inputObject.disabled for consistent results between browers.

Full testing results are tablulated at Testing the Disabled Attribute.

I thought I would create and ARIA example of Popup Help - turns out that is easier said than done. By Popup Help I mean a link or trigger element that is activated to display a block of help text that “floats” above the rest of the page. It seemed easy enough to implement until I started thinking about the features it should have:

• Focus needs to go to the popup help so that it can be closed via the keyboard. Setting it to close after a certain amount of time is not sufficient since people will need differing amounts of time to read the text.
• The popup needs to disappear when it loses focus or when the user clicks outside of the popup block. This means we need some sort of handler on the document to detect the click and close the popup. We need a close button or need to catch a press of the escape key to close the popup.
• If the popup has focusable items, you may want to trap keyboard focus within the Popup until the user explicitly closes it. Or, at least close the popup when the user pressed tab with focus on the last focusable item in the Popup.
• When the popup is closed, focus should go back to the trigger element.
• The popup needs to placed appropriately relative to the trigger element. This means that if the trigger is close to an outer edge of the current window, it must be displayed towards the inside of window. In other words, to make sure the popup is placed appropriately, some calculations need to be done to make sure it is visible and not clipped.

At this point the Popup Help suddenly seem like alot of work. Then I thought, “Hey, Dojo has a widget that does all that! Why don’t I just use the TooltipDialog?”. It places the dialog appropriately, it traps focus within the dialog until the user closes it, and it can be closed via the escape key or by clicking outside of the dialog. And, it is already ARIA enabled.

However, the TooltipDialog is triggered via a Dojo DropDownButton and most people want Popup Help triggered via a link rather than a button. So, my first step was to restyle the trigger element to look like a link. Even though I’m no CSS whiz, I was able to accomplish that!

When a TooltipDialog becomes active, focus is set onto the first focusable item within the dialog. A screen reader will announce “dialog” and the dialog title and then the item with focus. Popup Help is often just text and may not have a focusable item. How am I going to get the screen reader to speak the Popup Help text when it is displayed? Well, ARIA has a role of alertdialog. If I set the role of the TooltipDialog to alertdialog, JAWS 10 will speak the text. Since the TooltipDialog is hard coded with a role of dialog, I had to catch the event when the dialog is shown and change the role. Not too hard with Dojo’s addOnLoad function and dojo.connect().

So, with a little modification I was able to use Dojo’s TooltipDialog to create accessible Popup Help. Here is the working Popup Help example with code snippets to demonstrate the changes I made. Why reinvent the wheel when the hard stuff has already been implemented?

I have to admit that working on creating videos and captioned videos has been a humbling experience. I really don’t understand video on the web, yet, and wonder how so many youTube videos actually get created! I can certainly see why they don’t get captions - the process is tedious and can be confusing!

I used Camtasia 6.0 to record a demonstration video using the Dojo Sample Mail application with the JAWS 10 screen reader. I then used the IBM DigiCape program to transcribe the audio for me. That is certainly a big help! It is much easier to edit the captions than to have to try to transcribe it all myself. And, the Freedom Scienfitic folks might get a chuckle that “screen reader” often got transcribed as “supreme leader”!

After editing the transcript from DigiCape I used that text file to add captions in Camtasia. In theory, I should be able to give the video to DigiCape and it would synchronize the captions into the video for me - I’m still working on that and learning the DigiCape tool. It was fairly easy to sync the captions in Camstudio, although if you look at the result, you’ll see that I have a bit more to learn about line lengths, sizing and such. But, I at least have a 10 minute, captioned demo of Dojo widgets being used with a screen reader. I also need to get a better microphone as the video quality is poor and the volume not very high - I hope it is still usable! And, since the player is not accessible, the video is set to play automatically. Next step - learning about accessible players NCAM/CC and JW Player!

More to come as I venture into the world of captioned video!

Updated on May 14, 2009 - The South Africa Web Standards link no longer seems to work. I also updated the page with the embedded video so there should be fewer problems with it.

Through a tweet from AccessibleTwitter I was directed to a blog entry at The South African Web Standards and Accessibility Group that included a video posted on YouTube from a blind screen reader user on the importance of header elements for accessibility.

Since it wasn’t captioned, I did my best to add captions using a new, unreleased tool in development at IBM. It was presented at 23rd Annual Technology and Persons with Disabilities Conference - User Efficient Voice Recognition Based Caption Editing System (pdf). It was an interesting learning experience! Hope you enjoy.

Captioned Video on the Importance of HTML Headings for Accessibility

Also, if you want more demonstrations of how people use screen readers to navigate the web I suggest you search on YouTube for “screen reader”. Have Fun.

Say you have a set of invitations to connect to colleagues in your favorite social networking software. These might be listed one after another with an accept and reject button associated with each request. But, if someone is using a screen reader to just tab through the buttons on the page, how would you know which button is associated with each invite? Certainly the designers are not likely to want to put the user name within the button text, so how can we make this easier for the person using a screen reader or screen magnifier to access the page?

There are several different ARIA properties you could use. I created a sample page using 4 different strategies aria-labelledby, aria-describedby, aria-label, and the title attribute. See Augmenting Button Text with ARIA. I’ve included code snippets so you can see exactly how the techniques were implemented.

The first approach was to use aria-labelledby to label the button using text containing the associated user name placed within a span that is placed offscreen using CSS. Since the text is positioned offscreen it will not be seen but will be spoken by the screen reader. This seems to work the best with the various screen readers and ARIA supported browsers. However, it does require additional text and the use of CSS to place it out of view.

The next approach uses aria-describedby on the button to point to a span containing the User name text . This would augment the Accept and Reject button with the user name. This requires no additional text, you just need to include an id on the span (or other element) containing the user name text. This was not consistently supported in the browsers and screen readers.

Adding an aria-label onto the button element with the label for the button is easy enough. It does require the extra text as the value of the aria-label attribute but is easy enough to implement. Unfortunately, there is no current browser support for aria-label but it is coming in the next release of Firefox.

And lastly, just adding a title attribute on the button with the additonal information about which invite user it is associated with. This has fairly good support but does depend upon the user screen reader settings.

I compiled the results of testing with Firefox 3.0.8, a daily Firefox/Minefield build, and IE8 with JAWS 10, Window-Eyes 6.1 and NVDA 0.6p32 so you can compare the results and draw your own conclusions.

Hopefully the ARIA examples are helpful as well - I’ll try to do more!

Well, better late than never sharing my thoughts on SXSW! Thanks to Sharron Rush of Knowbility.org for organizing, I have been able to participate with her on accessibility related panels for the past two years. This year Sharron and I presented Ajax Accessibility: An ARIA Duet and I was also able to do a short presentation on WAI-ARIA at the More Secrects of JavaScript Libraries Panel. Presenting at the More Secrets panel gave me access to a large audience of JavaScript programmers to introduce them to WAI ARIA and explain how they can make their Web apps more accessible. I also got to show how Dojo has implemented ARIA and how other toolkits are adopting it as well. I think this introduction enabled us to pull more people into the Ajax Accessibility panel on the next day!

SXSW is a “cool” conference that combines the Web, Film, and Music and is thus very “youth” oriented with what seems an audience predominantly under 35 years old. Although, I was happy to see many faces in the over 40 and over 50 category as well! I heard that the attendance was up from last year which is a bit surprising but I guess indicates that perhaps tech hasn’t been hit quite as hard by the economic downturn. I was happy to see several panels and discussions that included accessibility:

Making Web Widgets Accessible: Tools and Techniques
Accessible Flash and Flex Applications
No Web Professional Left Behind: Educating the Next Generation
2009 WaSP Annual Meeting
Universal by Design
Deafness and the User Experience
Hack Ability: Open Source Disability Tech
Universal Design for Web Applications: Web Applications That Reach Everyone

I didn’t get to all of these, but I did my best! It is hard to get to all of the interesting talks at SXSW. I did attend Presenting Straight to the Brain and found it fascinating. I present code related topics often and do use many bullet points. The presentations by these folks were much more compelling and eliminated the bullet point overload. However, it did make me think how I would present something with less text, more talk and more pictures to a hearing impaired audience or to those who might rely more heavily on written words. I think the moral of the story is to have handouts with the full notes
for the session available to those who need it at the beginning. I’m hoping I can incorporate some of what I learned in my future presentations!

The Core conversation on Getting Things Done the Simple Way was packed - too many people squashed into a tiny room! I understand the idea behind conversations but when they get so large it kind of defeats the purpose. I know that Getting Things Done is popular but I guess I never realized just how popular and almost cult-ish it is! The misery of striving to say organized loves company, I guess!

There were plenty of “accessibility folks” at SXSW and it is nice to get a chance to see so many of my colleagues and meet new ones at parties and over drinks! There is a big Technology & Persons with Disabilities Conference the following week which may folks also attend (this was my first time not attending after 5 consecutive years). Thus, some of the folks from other countries combine the travel and attend both SXSW and the technology conference (referred to as CSUN since it is hosted by the California State University at Northridge - CSUN).

The podcast to the More Secrets of JavaScript Libraries Panel has been published. I’ve transcribed my part and posted more info at SXSW 09 Presentations.

FYI: I’ll be speaking at Knowbility’s John Slatin Access U in May, 2009. This is a great way to gain Accessibility and Design Knowledge! Check it out - early registraton discounts end April 10!

I joined the ranks of twitter recently but I feel more like I quack rather than tweet! It was fun at first to post what I was doing or where I was going but then I realized twitter is much more than just social. I decided to use twitter to increase my knowledge of accessibility and started searching for, finding and following folks in the accessibility field. Many of these are people I already know and I was relieved that they wanted to follow me, as well. I have already found some great folks to follow to keep me up to date on new a11y developments as well as users of all sorts of assistive technologies. Certainly twitter can be a great learning tool!

However, my problem lies in learning to tweet. I wonder how and where these folks find all the interesting things to tweet about? For some it is things they learn at conferences; for others it is the daily frustrations of using an inaccessible Web, for many it is sharing knowledge from their daily work. I, however, seem to fall short. Even when something interesting gets delivered to my mailbox I don’t seize the opportunity! For example, my colleagues in the Human Ability and Accessibility Center just released a new version of AccProbe - a tool for examining and testing Web sites for accessibility. I got an email, as did others in a subscription list, but I didn’t even think to send a tweet - someone else beat me to to it! Right now I am working on the dojox DataGrid code to make it more accessible. While I could probably tweet on the details of the DataGrid code, I’m not sure many folks would be very interested in the JavaScript details! Maybe I don’t spend enough time surfing or checking my RSS feeds, although I certainly don’t seem to have extra time in my day to do any more Web crawling. Then, I thought, I must just waste too much time on other non-work stuff but, I don’t think that is it either - after all, one must have some balance in life.

At any rate, this post hasn’t contained all that much about accessibility - other than I’ve found a new tool to keep me up to date in the a11y world. I guess eventually I’ll learn to tweet better or else I’ll just have to enjoy the benefit of learning from the wonderful songs of others!