“Are your customer experiences accessible to people with disabilities?”

“I’m not sure, but I don’t think it’s that important because we don’t have any customers with disabilities.”

I shudder when this happens.   15%-20% of the population [1] has a condition that they consider to be a disability, and the days are gone where your organization can pretend that it doesn’t interact with these folks.

11% of North Americans currently use Apple computers [2], and no business to consumer organization would ever want to make it impossible for these users make a purchase from their website – yet this is what many do each day when they forget to design customer experiences to accommodate the special needs disabled people.

Is your web experience Accessible?  We recommend you use the free non-profit utility below to do a quick check of your site.  You might be surprised at what you learn.

Check your site now with WAVE

Sources:
[1] UN Nations Convention on Rights of Persons with Disabilities, 2007
[2] Mac OS X North American install base almost 11%

I can tell you from experience that no Product Manager likes to fill in a ‘ Supports with Exceptions’ entry when compiling quarterly updates to company VPATs, particularly when we have been so passionate about closing accessibility gaps as quickly as humanly possible. With our RightNow CX February 2011 release, I am delighted to say, we finally address the last of our gaps on timed responses. Why did it take so long to finally addressing the bane of 1194.22(p)? Sometimes its hard to explain exactly why some things that seem easy take longer to plug, but this one kept raising its ugly head every time I went back to update our docs. Not that we’d kept people using accessibility tools dangling – our form completion compared to other comparible solutions had very generous time constraints for completion, and even allowed for an admin override to give up to 2 hours of time to complete a form, but when you are so proud of all the love and attention paid to accessibility in the rest of the experience, the tinniest molehill becomes a mountain. So, we dragged ourselves away from all the other priorities that crowd our calendars and rolled our sleeves up and got it done. Finally!

RightNow customers will get to enjoy this new feature in our newest release!

Image of the Timed response extension dialog

That’s not saying that all gaps can ultimately be easily filled.  One gap that will prove to be very hard to fill is Dallas Despain, who is leaving us for another opportunity (unfortunately not accessibility related) in his native Salt Lake City. We’ll miss you Dallas! Thanks for being such a passionate advocate for accessibility during your stint at RightNow. Good luck with the new opportunity and we hope that we’ll bump into you soon!

CR 48 Chrome OS laptop

Of course, this post is way too late to be news, and there are many detailed web sites that explain the CR 48 much better than I will here. But if you don’t know about the CR 48 I will simply say that it is a piece of reference hardware meant to test Google Chrome OS which is a chrome-browser-based operating system meant to be very fast, secure, always connected, and which only supports cloud based applications. Go to the chrome OS pilot program website to learn more and apply to receive your own CR 48!

I won’t really review the device except to say that I love using it, it seems to work very well, it does everything I need while on the go, and my wife has officially stolen it and refers to it affectionately as “the chrome”! As I said before, I have been wanting to write about accessibility in chrome OS since I got the device, but I haven’t been able to write this post because when I enabled the accessibility options nothing happened.

Chrome OS System Settings Screenshot - Accessibility Options checkbox circled

I did a few Google searches and I was able to find this Google Chrome OS Accessibility help page which basically says Chrome OS contains a screen reader! The screen reader is provided via a Chrome extension called ChromeVox and has the following features:

• The sign-in screen speaks — user name field and password prompts are spoken. Your password is *not* echoed when you type it for obvious reasons.
• Once you’re signed in, the talking extension, ChromeVox, is activated. With ChromeVox active, you get spoken feedback for all user actions. For example:
  • All the Chrome menus talk.
  • Opening webpages produces a combination of spoken feedback and non-speech auditory cues.
  • Access the set of extensible keyboard commands by pressing the search key. You can press any number of key sequences to navigate web content in a variety of ways, e.g. pressing ‘h’ while holding down the search key moves through the page by headings; pressing the arrow keys while holding down the “access” key moves through the elements on the current page and speaks them intelligently as they are traversed.

Obviously, I was really excited about these features but I could never figure out how to get them working. Finally, I decided to contact a Chrome OS “Ninja” about it.  They responded to my request very quickly and helped me figure out the problem. Here is his response:

“After a bit of investigating, the accessibility feature was disabled because it was not ready for prime time.  It is expected to be finalized for the next ChromeOS release.
Should be sometime in the first quarter..

So one morning you will wake up and your CR-48 will magically provide accessibility
features. ”

So that’s my update. It’s confirmed that Chrome OS will contain accessibility features but not yet. When they come that will be another very good day!

So, setting tabindex=”-1″ on my aria-describedby element fixed my whole problem!

The code looked something like this:

<div role=”dialog” aria-describedby=”myDescription”>

<div id=”myDescription” tabindex=”-1″>My awesome accessible dialog.</div>
….

Here’s a list of Dom elements that Internet Explorer considers “accessible”

We are still working on a page set that ultimately will not use javascript – so our plans haven’t changed – even though the timelines have changed a little bit over the last few months (we’d originally wanted to release a script free javascript experience this year as part of our mobile release) but conflicting project priorities (including adding accessibility support for guides and the mobile experience)  has delayed that.

Anyway, interesting comments on the script/no script debate in another blog from Webaim – who are taking the steps to require javascript on the WAVE evaluation tool. A great read (don’t miss the comments) for those of you with an interest in this debate on this topic is http://webaim.org/blog/javascript-as-an-accessibility-concern/. The debate will continue to run!…

On a similar topic , check out a great video from Dennis Lembree at YUI talking about making Javascript accessible – http://developer.yahoo.com/yui/theater/video.php?v=lembree-a11y.

Update: added screenshot below

Are you looking for a quick way to improve the accessibility of your site? We recently added ARIA Landmarks to our Customer Portal reference implementation and they were easy and fun to add.

Basically, landmarks provide a simple way for assistive technology users (for example screen reader users) to quickly jump between sections of your webpage such as your banner, navigation, main content, footer areas etc… Almost all webpages have some elements in common, and ARIA landmarks leverage that commonality to give users of assistive technology a quick way of jumping around your site.

Landmarks are the next generation of the idea behind skip navigation links. In Jaws 10+ you can use the ; and shift + ; keys to cycle through different landmarks. As you go JAWS announces the name of the landmarks such as “banner”, “navigation”, “main content”, etc. Important! landmarks don’t replace the Skip Navigation Link because they are not fully supported yet.

As many people have already pointed out, Apple’s new iPhone operating system iOS4 includes the ability to navigate landmarks using the excellent iPhone screen reader VoiceOver.

This was my first time using landmarks even though I had known of their existence for some time. Now that I’ve experienced them directly I wish I hadn’t waited so long. The code is really simple:

All you need to know is a little bit of HTML. Simply look at your HTML and find the sections that you want to mark. When you find a section, add the role attribute and set it like so:
<div id=”nav” role=”navigation”>…</div>

or <div id=”content” role=”main”>…stuff</div>

Using the The Juicy Studio Accessibility Toolbar you can visualize where all your sections are.

Here’s what our product looks like with landmarks added.



The Juicy Studio Toolbar highlighting ARIA Landmarks in Customer Portal

Check out Steve Faulkner’s excellent post for an in-depth tutorial on landmarks including a list of all possible role values and ways to make sure that your markup still validates.

Those of you with an interest in web usability in general and web accessibility in particular will be no doubt excited by the announcement on July 23rd by the United States Department of Justice of an Advance Notice of Proposed Rulemaking (ANPRM) governing accessibility on the web beyond Federal government. Not only is the intention to extend the remit of existing legislation to cover State and Local Government interaction by revising with citizens in a revision of Title II, but the intention is also to regulate any business that supports a ‘public accommodation’.

As referenced on http://www.ada.gov/anprm2010/web%20anprm_2010.htm, Title III of the ADA provides that “[n]o individual shall be discriminated against on the basis of disability in the full and equal enjoyment of the goods, services, facilities, privileges, advantages, or accommodations of any place of public accommodation by any person who owns, leases (or leases to), or operates a place of public accommodation.” 42 U.S.C. 12182(a). Title III of the ADA and its corresponding regulations define a “place of public accommodation” as a facility whose operations affect commerce and that falls within at least one of the following 12 categories:

(1) An inn, hotel, motel, or other place of lodging, except for an establishment located within a building that contains not more than five rooms for rent or hire and that is actually occupied by the proprietor of the establishment as the residence of the proprietor;

(2) A restaurant, bar, or other establishment serving food or drink;

(3) A motion picture house, theater, concert hall, stadium, or other place of exhibition or entertainment;

(4) An auditorium, convention center, lecture hall, or other place of public gathering;

(5) A bakery, grocery store, clothing store, hardware store, shopping center, or other sales or rental establishment;

(6) A laundromat, dry-cleaner, bank, barber shop, beauty shop, travel service, shoe repair service, funeral parlor, gas station, office of an accountant or lawyer, pharmacy, insurance office, professional office of a health care provider, hospital, or other service establishment;

(7) A terminal, depot, or other station used for specified public transportation;

(8) A museum, library, gallery, or other place of public display or collection;

(9) A park, zoo, amusement park, or other place of recreation;

(10) A nursery, elementary, secondary, undergraduate, or postgraduate private school, or other place of education;

(11) A day care center, senior citizen center, homeless shelter, food bank, adoption agency, or other social service center establishment; and

(12) A gymnasium, health spa, bowling alley, golf course, or other place of exercise or recreation.

So, what are your thoughts on the impact of Title III? How easy will it be to determine whether a section of private sector web real-estate is for ‘public accommodation’ or not? Are there going to be accommodations or grace periods for private businesses to build out accessibility into their web experiences? If so, how long are those grace periods likely to be? Are we effectively at the point where any web experience, regardless of whether it is associated with a physical location or a virtual entity is going to be regulated? This revision, if ratified, will certainly (and quickly) lead to test cases in the courts allowing them to determine the breadth of application – but how long will it be before the web (both for US consumers and consumers worldwide) will become truly accessible?

The outcome of the upcoming 180 days of public consultation should be interesting indeed!

My struggle with Google Docs

I‘ve always been really excited about cloud computing in general, and I’ve been trying to use Google Docs for four years now. My first document was created on June 6th, 2006. It’s an empty spreadsheet – obviously just a test. Several times I’ve tried to move to the cloud permanently, but I’ve always found myself stuck in between with my head in the clouds, and my feet on the ground, so to speak, firmly planted in the fertile soil of Microsoft Office 2007 (OpenOffice is very good too).

There are probably many reasons I have been unable to make the switch, from “incompatible with my company’s work flow processes”, to “lack of features compared to desktop versions”, but as I’ve pondered my conundrum this morning, one giant, mind blowing reason stands out to me: I can’t use any of the Google Docs apps without constantly reaching for my mouse! (Or so I thought until today…)

Mouse got your tongue?

Maybe it’s just me. Maybe it’s because I’m a developer and I’m constantly using VI. Maybe it’s because I specialize in web accessibility. Maybe it’s because I struggle with carpal tunnel issues and use a weird keyboard. Maybe I’m just crazy, but I detest using my mouse! I admit it, I’m an extremist, a zealot, a nutcase. Whatever the case may be, I find that once I become familiar with an application and learn its keyboard shortcuts, I experience a drastic boost in productivity when using the application.

Of course, it can take a considerable amount of effort to learn the keyboard shortcuts for any given application and sometimes it’s easier to just stick with your mouse. In fact, case in point: Google Docs does provide a list of keyboard shortcuts. Did you see that thing? Who has the time to memorize that?

For me, Microsoft Word 2007 makes it easy because I don’t even have to memorize shortcuts. I simply use the ribbon. I just press the alt key and I immediately see which keys I need to press to get to the option I am looking for.

Keyboard Access to the Ribbon in Microsoft Word

I could never get over the constant distraction of taking my hands off the keyboard, and grabbing the mouse to use Google Docs commands. It appears that is about to change for me…

Keyboard only Google Docs and Microsoft Web Apps

Today I was reading about a Microsoft Campaign to get people to switch from Google Apps to Office Web Apps and I thought I would give it a try to see if they had improved the keyboard accessibility of web-based authoring tools. The first thing I noticed when using Office Web Apps was that when I pulled up the help tool, I immediately saw a link to Accessibility features in Office Web Apps, big bonus Microsoft! It took me much longer to find an article about using Google docs with a screen reader on Google’s help site.

It turns out, you can access the menus in both Google Docs and Office Web Apps if you know the right keystrokes:

Google docs:

Keyboard access to Google Docs Toolbar (blue focus indicator)

• Press the escape key to stop editing your document and use the menus
• This did not work in Google chrome?! but it did work in Firefox.
• When you first press escape, there is no visual focus indicator to make you aware of the fact that you are focused on the Google Docs File menu dropdown. It’s easy to get lost. After pressing the right arrow you do get a visual focus indicator.
• Using the arrow keys to navigate the menus works really well. Tab in between toolbars.

Office Web Apps

Keyboard access to Word Web App Toolbar (dotted line focus indicator, blue File tab is current tab)

• Press Ctrl + F6 to stop editing your document and move focus to the Home menu.
• Instead of using the arrows to navigate the menus, one must press tab incessantly to find the command you want. This is not nearly as quick as the desktop Ribbon UI.
• Visual focus behaves as expected – I never felt lost.
• As usual, everything works better in Internet Explorer

All in all, I’m excited by this new-to-me revelation. Maybe I will give word processing in the cloud another try, however my enthusiasm is dampened by the ever-present browser inconsistencies, app keyboard shortcuts that clash with browser keyboard shortcuts, and a reliance on too much tabbing to do get to the command I want.

For now, I think I will stick with my desktop word processing App for long bouts of writing. That said, I can’t help but try every cloud app out there. After all, I’m writing this post in Google Wave. Don’t even get me started on accessibility and keyboard operability there.

What do you think about the keyboard vs mouse controversy? Do you prefer desktop Apps or Web apps?

Our QA department has a rigorous testing process and won’t rest until we’ve created the best possible web user experience for our disabled users.

We thought it would be interesting to share one of the accessibility issues that came up recently in our product testing. This issue illustrates some of the difficulties and challenges associated with making a product accessible.

In accessibility there are so many factors at play including: operating system, browser, type of assistive technology being used, screen reader brand, screen reader version, disability type and more.

A good example to share is one that we have recently been working through. During our regression testing for an upcoming release, we noticed a problem with JAWS 11 when reading a link that contains both anchor text and an image with alt text. The following link (which doesn’t go anywhere since it’s just for demonstration purposes) is an example of this:

Learning from the Web

As you can see, this link contains the anchor text “learning from the Web.doc” and an image with alt text reading “Microsoft word document”. When using the tab key in JAWS 11 to read the example link we found that just the alt text of the image “Microsoft Word document” is announced. This leaves out vital information about the link, namely the rest of the anchor text which reads “learning from the Web.doc”.

Interestingly, if you use the arrow keys to read the link then both parts of the relevant information are announced as expected. To complicate matters further, we found order to be important in this issue. If we were to change the link by putting the anchor text before the image, then just the anchor text is announced when using the tab key and not the alt text of the image.  The following link is an example of this:

Learning from the Web

In our testing, we found that this only occurred in JAWS 11. In JAWS 10 both parts of the link are announced as expected.

We’re not exactly sure how much impact this would have on our screen reader users, because we suspect that most users use the arrow keys to read content, but if they use tabs then they would be missing information.

So, a product issue possibly, but not something we necessarily have the ability to fix. Regardless, these type of issues result in a lot of review and introspection during testing. You will be happy to know that our inability to correct something isn’t the end of the line for us. We thought that this discrepancy was important enough to submit an incident with Freedom Scientific, the company behind JAWS. We’re not sure yet if they’ll consider this a product defect and fix it in an upcoming release or not but we’ll let you know as things progress.

So we hope you enjoyed this peek into our QA process and can see that we try hard to research even the small issues and find ways to correct them so that all of our users have a better web experience.

Below are some experts from the document:

“It is not possible to provide a definitive specification for a fully accessible web site which will satisfy the requirements of the DDA” [H.1.1] … “Only the court can decide”[E.8]

“Evidence that a web site conforms to WCAG Level A or higher will be useful but it less likely to be influential before a court or tribunal than evidence of successful user testing.” [E.8]

This is quite a different approach to accessibility that recognizes the difference between the following:

1. Content that is technically ‘visible’ to a screen reader (Access).
2. Content that enables the user to achieve their task (Use).
3. Content that facilitates a good experience (Enjoyment).

The overall feel of BS8878 seems to imply that a customer in the UK who has a bad experience with a company due to their disability is entitled to sue that company, regardless of that organization’s adherence to any technical standards.

Here’s our interpretation: because a human judgment (a court or tribunal) is required to recognize a violation of the DDA, every organization must be able to tell an honest and compelling story about the “reasonable steps” they took to ensure disabled users will have a good experience with their product or service.

Going above the minimum ‘reasonable steps’, has your organization gone beyond the call of duty to deliver a great customer experience to all of your customers?

Would you be willing to share what you did?