This is part two of my three-part series sharing my recent email interview with Jennison Asuncion. If you missed it, check out part one, “Interview with Jennison Asuncion.” Today, we talk about the state of web accessibility in North America, and the prognosis for the future.

Steve (SG): What do you think the state of web accessibility in North America is right now? How would you grade the progress made thus far?

Jennison (JA): I would say web accessibility is in a pretty dynamic state right now, pardon the pun. The release in December 2008 of the much needed version 2 of the Web Content Accessibility Guidelines, along with other work by the W3C’s Web Accessibility Initiative (WAI) in where they are finalizing guidance on how to make dynamic content using AJAX and other technologies accessible via Accessible Rich Internet Applications (ARIA) is getting us to a better place when it comes to having a set of specifications to help broadly address Web 2.0 and accessibility.

In addition, companies are pushing out toolkits and libraries that contain accessible widgets and components that developers can use, such as IBM’s work on Dojo Dijits and Adobe’s work on Flex. There’s an excellent piece done by The Paciello Group identifying a number of accessible JavaScript UI Libraries.

And definitely not to be overlooked are the ongoing efforts of organizations such as: Mozilla, the Adaptive Technology Resource Centre (ATRC) here in Toronto, and Drupal, which are active communities making significant contributions to improving the state of web accessibility

People are increasing in both their appreciation for the importance of accessibility, and in their knowledge of how to code in an accessible way. This is thanks, in no small part, to dedicated organizations such as: WebAIM, the Illinois Center for Information Technology Accessibility, Equal Access to Software and Information (EASI), and Knowbility, each of whom provide accessibility resources, training, and in some cases tools, to the web community at large.

In fact, WebAIM and ICITA have developed free tools that folks can use, in part, to help test the accessibility of their websites. These include WebAIM’s WAVE and the Functional Web Accessibility Evaluator from the ICITA.

Admittedly, some of the effort driving web accessibility is being brought on thanks to legislative encouragement, such as the lawsuit involving Target.com, and the upcoming introduction of the Information and Communication Standard of the Accessibility for Ontarians with Disabilities Act (AODA). On the flip-side, I am always coming across developers who are genuinely wanting to make web experiences as accessible as possible. Dennis Lembree is one example of someone who saw gaps in the popular Twitter app, and decided to build Accessible Twitter.

I’m seeing a new business case being built and used, linking how developing sites to be accessible benefits not only users with disabilities, but also those using mobile devices to access the web, older-aged users, as well as search engine optimization. This positioning of increased benefits for the larger population, to me, can only help build the web accessibility value proposition in a more tangible way for those looking at the bottom line who still need convincing.

Through e-mail discussion lists and social media, I’m seeing an increase in the level of constructive conversations on web accessibility among and between the developer, the IT accessibility professional, and the end-user with disabilities communities taking place. Some of these conversations, I’ll say, are long overdue, but at least they are happening.

Finally, I’ve been fortunate enough to be exposed to a thriving and active research community where some of the brightest minds are trying to solve web and mobile accessibility challenges by building software and hardware solutions of all kinds. Jeffrey Bigham’s WebAnywhere – a browser-based screen reader, is just one example. If the opportunity presents itself, I encourage readers to attend an Assets or a W4A conference. There are others out there too, where there is a heavy emphasis on research-driven work.

Is it all a good news story? While the number of people who know about web accessibility or what needs to be done to make sites and applications accessible is on the rise, websites and applications are launched daily, for whatever reason, with little to know consideration for accessibility.

There are still common misperceptions out there such as: people with disabilities don’t use the web; adding alt text to images is all that is needed to make a site accessible; the only web users with disabilities needing consideration are blind JAWS screen reader users; accessibility can be dealt with at the end of development or in a “next” release; or making a site accessible will: take too much time, cost too much, and impact creativity.

The W3C’s Web Accessibility Initiative is certainly doing work around outreach and education. However, I still hear people lament about how looking at the Web Content Accessibility Guidelines (WCAG) V2.0 documentation is overwhelming, when all they want and have the time for is a handy list of what is required to make a site accessible.

Development tools, frameworks, and technologies are constantly changing, and these are being released at lightning speed. To further complicate matters, while technology vendors may make available accessible widgets, the reality is, developers may want or need to customize them or use others that are not accessible because they work better based on client requirements. Or, they may choose to build their own components altogether. Each of these situations will have an impact on how accessible the final end-product will be. Add to the mix the fact that many adaptive technologies, such as screen readers, screen magnification, and dictation software that some users with disabilities need in order to interact with the web are just not keeping up to pace when it comes to being able to work with the latest and greatest in rich internet technologies.

Involving users with disabilities in testing throughout the development lifecycle and/or using different combinations of browsers and adaptive software during testing, is still not commonplace. This is key, especially since much of the accessibility of rich internet applications rests on how techniques, controls, and technology are being implemented. This can only be validated through testing, and who better to test than the typical end-users themselves.

SG: Where do you see accessibility heading in 2010, and beyond?

JA: I’ll answer the question by saying where I’d like to see accessibility head in 2010 and beyond. We need many more real-world examples of websites and applications in the mainstream, as points of reference, which showcase how to use the latest and greatest widgets and technology in an accessible way. To be truly useful, these need to include not only sites that contain textbook perfect implementations, but also others that have varying levels of complexity that call for some level of thinking outside-of-the-box in order to make the site accessible.

We need to redouble our efforts around education and outreach, where the focus shifts from what is seen by some as preaching and prescriptive, to practical, hands-on, useful information using language that devs and others speak. This is especially critical given the emphasis today on initiatives like Government and health 2.0, and the mobile web, who knows what’s next.

I am excited by the emerging grassroots efforts to explore adopting the unconference model to educate and communicate with the development community on IT accessibility. This is just one way, and there are certainly other methods out there, such as exploiting YouTube.

I am worried that if we do not put a focus on education, that developers, in the absence of information they can use immediately, will go ahead and implement accessibility the best way they know how, potentially incorrectly, which will only lead to inconsistencies across the board.

At the same time, we also need to make it easy for people to make things accessible. This is especially true in our world of user generated content, where Grandma Sue could be posting a video. If adding captions requires a degree in Computer Science, she won’t do it.

The vendor community of screen reader, screen magnification, voice recognition and other adaptive technologies needs to be more visible and active in the ongoing accessibility conversations that are happening real-time. They need to be faster to market, and the technology needs to be compatible with what is being pushed out today, so that someone with a disability isn’t waiting for a new version of product X in order for them to use all of the features and functionality of a website that launched yesterday.

As an IT accessibility professional who happens to be blind, I would like to see more people with disabilities get involved in the field of web accessibility in the years to come. As a profession, there is absolutely a need for more people with disabilities working at the testing and coding level. However, we also need more people with disabilities at the tables where business, thought, policy, and IT conversations are taking place that will shape where the web will be headed in the years to come.

In the final installment of this interview, Jennison will give advice on how to deal with obstacles that the business world may put up in one’s quest to make web sites more accessible. I’ll also share some final thoughts about this outstanding experience.

Stay tuned!

Series Recap:
Interview with Jennison Asuncion – part one
Interview with Jennison Asuncion – part two
Interview with Jennison Asuncion – part three and wrap-up

Tags: accessible rich internet applications, adaptive technology resource centre, ajax, aoda, aria, assistive technologies, easi, flex, icta, jaws, jennison asuncion, knowbility, toronto, wai, WAVE, WCAG, Web Accessibility Initiative, Web Content Accessibility Guidelines, WebAIM

In my last post, I began sharing many thoughts about my visit to IndependenceFirst on Monday, to attend “Multiple Facets of Accessible Design.” It was an excellent presentation facilitated by MilwauCHI.

I rambled so excitedly in my coverage of Shawn Henry’s presentation that I needed to split things up into multiple blog posts to do them justice.

The second presenter was Scott Mayer from American Family Insurance, a usability services specialist who became blind at the age of 24.

He led off with some interesting statistics about disabled people in the United States:

Scott then demonstrated how he uses the Internet via his JAWS screen reader. I’ve got to tell you, that was one of the most revealing experiences I’ve had since focusing on accessibility.

I’ve been tackling the subject in my own incremental way, and while I’ve watched a video here and there demonstrating screen readers, there was something completely different about seeing one in action.

Scott showed examples of good and bad accessibility using his screen reader. On one site, he showed how he was unable to pay a bill on a banking site because the actionable button for signing on was invisible to the screen reader.

Another interesting point – Scott talked about how many sites, particularly in the financial sector, tend to go through redesigns often. Some financial sites do it almost quarterly. While constant evolution and enhancement may seem like an all-around great idea, somebody like Scott has to completely re-learn how to get around that site each time they retool it.

Scott explained how automated accessibility testing is not enough. There is no replacement for usability testing with disabled users.

People tend to treat disabled consumers like Scott differently, thinking them to be less educated or poorer. He shared an experience in which he and his wife took their car in for repairs, and how the attendants didn’t even consider for a moment that a blind user may know something about car repairs. They barely acknowledged him.

Physical stores tend to be useless to somebody like Scott. He frequently utilizes the Internet to buy things and have them shipped to his home.

Just because somebody is blind, or deaf, or has some sort of disability, don’t assume they are less intelligent or some poor, destitute person. It may be easy for some businesses to dismiss what they assume is an insignificant minority of potential visitors to their web site, but there is an awful lot of ignorance steeped in that attitude.

And I haven’t even gotten to my first tour of IndependenceFirst! We’ll save that for next week’s posts!

Tags: assistive technology, IndependenceFIRST, jaws, milwauCHI, milwaukee, Scott Mayer, visually impaired

This week, thanks to a friend and colleague at Hello Goat Designs, I had the opportunity to do some accessibility testing on a web site he is building. I’ll share more about my findings and the final result when the site launches.

There were a few basic accessibility tweaks that I suggested, one of them relating to header tags. That gave me the inspiration for another post in my Web Accessibility 101 series.

There are a few things worth noting about properly and effectively using H1, H2, etc. These basics not only help provide an easier navigating experience for the disabled, but also get wins in search engine optimization.

Screen readers like JAWS have key commands to read off header elements, in order. For example, JAWS has a command INSERT + F6 that reads the entire list of headers, and H cycles the user through each header. The browser Opera allows you to highlight across header elements via its single-key shortcuts.

H1 should be the top level heading of a document. Often times this would be the page title. It gets huge consideration from search engines. There should only be one H1 per page.

You can use any number of H2 tags, H3 tags, and so on. And while there are six header tags, you don’t need to use all of them. There may be cases that only H1 and H2 are needed, for example. If H1 is your page title, H2′s are major headings, followed by H3 sub-headings, and so on.

Avoid skipping header tags. If there are H3′s on your page, there better be H2′s and an H1 as well. Skipping causes confusion for screen readers.

Header tags should be wrapped around actual headers or titles, not blocks of code or content. This came to mind because I recently saw a site (that was built using SharePoint Designer), that had actual tables within a header tag. That’s all kinds of wrong.

Header tags, in short, are more than just stylistic additions. For screen reader users, they are vital in giving a sense of the main topics of the page, and enabling easier navigation through your content. Additionally, effective header tag usage will get you superior search engine treatment — making your site more accessible to everybody, not just the disabled.

Tags: h1, h2, h3, header tags, jaws, opera, screen readers, search engine optimization

WebAIM recently posted results to a survey of screen reader users, conducted from December 2008 – January 2009. In Survey of Preferences of Screen Readers Users, they share very interesting results regarding the usage of screen reader technology in web navigating.

Some of the initial findings perhaps aren’t surprising. Of the 1121 participants, the vast majority (nearly 90%) use screen reader technology all of the time and because of a disability. 96% of them cited visual impairment, in most cases outright blindness.

The breakdown of screen reader usage is insightful:

• JAWS – 74%
• Windows Eyes – 23%
• NVDA – 8%
• VoiceOver – 6%

(WebAIM points out that percentages often don’t add up to 100% due to rounding, and in this case also because of the possibility of usage of multiple products)

Most of the participants utilize desktop PCs (78%), with just over half use screen readers on a laptop. Those using mobile technology with screen readers made up a much smaller 12%.

Lastly (for this post), web browser usage breaks down as follows:

• Internet Explorer 7 – 68%
• Firefox – 39%
• Internet Explorer 6 – 33%
• Safari – 6%
• Internet Explorer 8 – 2%

Amongst the nearly 7% of participants who used screen readers though were not disabled (some for evaluation purposes), Firefox usage was twice as prevalent. It was also noted that the question was not worded “primary” browser, just browser usage, and that IE8 and Safari were, essentially, write-in votes.

While none of this is exact science, the findings are all-around very interesting and offer a glimpse into the methods and practices of screen reader users.

I’ll close for now, having focused on the software and hardware findings. There are a slew of results covering browsing tendencies, from home page navigation to access keys to Flash and imagery frustrations/ease of use.

All in all, these results are well worth combing through and considering when evaluating accessibility, particularly as it relates to the visually impaired.

Tags: blindness, jaws, NVDA, screen readers, survey, visually impaired, VoiceOver, WebAIM, Windows Eyes

It’s no great revelation that many people use Internet Explorer to comb the web, while others prefer Firefox or Safari. Some are giving Chrome a go, and a small percentage hop around cyberspace through Opera. Those of us in the web design and development world use all of the above (or at least should!)

I remember, back in my college days when the Internet was first making its foothold, I used the text-only browser Lynx to putter around, mostly because I had problems getting Mosaic to work on my Mac and 2400 modem.

As I began researching web accessibility, I was surprised to read that people still use Lynx.

Sure, there are people restricted by low bandwidth Internet access who would sooner get to where they are going than endure painfully long load times.  But Lynx by its nature has an attribute that makes it particularly appealing to people with certain disabilities — because it strips down a webpage to its most basic, GUI-less state, and can be completely navigable by keyboard. For someone with physical limitations that affect the motor skills necessary to navigate with a mouse, strict keyboard navigation is much easier.

Some other assistive technologies that aid the disabled in their web surfing:

JAWS™ screen reader
JAWS is long-standing software that enables the visually impaired to navigate Windows more easily. It uses text-to-speech technology and also interacts with refreshable Braille displays (to be discussed in a moment). Working over the top of Windows, it begins its speech capabilities upon startup. A user navigates using keyboard commands and shortcuts. This extends to Internet Explorer as well, reading aloud what is displayed through the code of the web page.

Naturally, as we’ll talk about at length in future posts, how accessible a site is determines how well programs like JAWS present its material to blind visitors.

Like a lot of assistive technologies, JAWS is not inexpensive. It runs $900 and up. Another option in roughly the same price range is Windows-Eyes.

VoiceOver
Built right into Apple’s OS X since 10.4, VoiceOver allows users to navigate about their Mac using keyboard commands and voice. It works with Braille displays and boasts being very intuitive for users of Windows-Eyes and JAWS who are switching to Mac. 

Refreshable Braille Displays
Some blind computer users prefer to use speech technology to navigate, while others opt for Braille. Refreshable Braille displays, in layman’s terms, raise dots to form the Braille that enables the visually impaired to read whatever the screen reader is capturing. As an example, Freedom Scientific offers 40-cell and 80-cell displays. Their devices are quite expensive in their own right, roughly $4000 and up. The ALVA Refreshable Braille display is another example.

Screen Magnifiers
Built in to Windows, Mac OS X, and several flavors of Linux is “magnifying glass” type of technology, to enable those who are visually impaired by limited sight to zoom in on whatever they want on their computer screen, including web browsers.

There are certainly other assistive technologies that will crop up in future posts. These are but a sampling. Feel free to pass along others worth mentioning in the meantime. As I continue along with my Web Accessibility 101 series, I hope to better flesh out the user experience that various disabilities create. 

Web accessibility — specifically, how designers and developers build out their sites — make such assistive technology’s jobs easy or very difficult.

Tags: accessibility, assistive technology, braille, jaws, screen magnifiers, screen readers