ARIA & Accessibility & Dojo 07 May 2009 10:41 am

Creating Accessible Popup Help with Dojo and ARIA

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?

twitter 03 May 2009 05:00 am

Twitter Weekly Updates for 2009-05-03

  • great read! RT @slger123 Just posted my love story about my “talking ATM” at asyourworldchanges.wordpress.com. Talks so nicely. #
  • Saw interesting prz by Dan Ingalls from Sun today on lively kernel. No a11y, yet bit pretty cool what they are doing with JavaScript #

Powered by Twitter Tools.

Accessibility 01 May 2009 04:44 pm

Learning about Video and Captioning

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!

Accessibility 27 Apr 2009 07:22 am

Captioned Video on Importance of Header elements for screen reader users

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.

twitter 26 Apr 2009 05:00 am

Twitter Weekly Updates for 2009-04-26

  • Managed a SLOW 1.5 mile jog, walked the 2nd half. Will see how hip tendinitis is. Gotta start somewhere! #
  • Sitting on the deck sipping sangria! Finally some nice weather! #
  • off to tackle making drag and drop icons for dojox.DataGrid column reordering visible in high contrast mode - a11y job security, I guess! #
  • keyboard navigation of hidden columns checked into the dojox.DataGrid as well as keyboard navigation into grid with hidden headers. #Dojo #
  • trying to implement accessible bubble help - finding it is more difficult than I anticipated. Using Dojo dijit.TooltipDialog seems easiest! #

Powered by Twitter Tools.

twitter 19 Apr 2009 05:00 am

Twitter Weekly Updates for 2009-04-19

  • just checked in updates for Dojo drag and drop low vision accessibility http://tinyurl.com/dz2mzc #Dojo #A11y #
  • making good progress implementing keyboard navigation past hidden columns in Dojox DataGrid - wondering what I missed! #Dojo #

Powered by Twitter Tools.

twitter 12 Apr 2009 05:00 am

Twitter Weekly Updates for 2009-04-12

  • just checked keyboard column resizing into dojox DataGrid. Still some bugs to work out but making keyboard a11y progress! #Dojo #
  • Hey, I made the IBM Human Ability and Accessibility Center Events page! http://tinyurl.com/5vpcgl #
  • interesting discussion of ARIA role=presentation in Free ARIA google group: http://tinyurl.com/cbzz86 #
  • trying to fix dijit unified event handler to deal with space, enter and click in one place- differing browser behavior is frustrating! #Dojo #
  • ARIA support for Google Calendar, Finance and news: http://tinyurl.com/dlfpmy #
  • ARIA support for Google Calendar, Finance and News: http://tinyurl.com/dlfpm #

Powered by Twitter Tools.

ARIA & Accessibility 09 Apr 2009 09:59 am

Augmenting Button Text with ARIA

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!

twitter 05 Apr 2009 05:00 am

Twitter Weekly Updates for 2009-04-05

Powered by Twitter Tools.

Accessibility & conferences 31 Mar 2009 08:27 am

Thoughts on SXSW 2009

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:

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!

« Previous PageNext Page »