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

Next week, the Paciello Group — an organization that works with all manner of entities from governmental to commercial to ensure their technologies are accessible for all people — will be presenting a webinar on Flash and accessibility on Tuesday, March 31st.

There is also one on Wednesday, April 1 about PDF forms and conforming to WCAG 2.0 standards.

Both will take place at 11 a.m. Central time.

Adobe has more details in an entry on their accessibility blog entitled “Accessibility webinars on Flash and PDF.”

Related Links:

• The Paciello Group and Adobe Present WCAG 2.0 Accessibility Webinars for Flash and PDF
• Adobe’s Accessibility blog

Tags: Acrobat, adobe, flash, paciello group, PDF, WCAG

As I eluded to in my post about getting accepted into the Guild of Accessible Web Designers, I had to make some edits to this site to strength its overall accessibility.

Some of these changes stemmed from WordPress limitations and others were just things I missed or wasn’t aware of. All in all, though none of the changes were out-of-this-world complex or obscure, it was an excellent learning experience for me. While this site’s accessibility no doubt isn’t “perfect” yet (is such a thing possible?), I feel better knowing that I’ve made definitive strides forward.

Here are some of the changes that were recommended to me by GAWDS:

Skip Navigation option
This is perhaps less of a must-have on a site like mine without header navigation, but it is advisable to provide an option at the top of your site for skipping straight to the main content.

Screen readers read from top down, and as such, when a visually-impaired navigator hits each page of a site, he or she has to hear the navigation spoken aloud before getting to the meat of the page. Providing the ability to skip past that to the meaningful content makes the experience much more straightforward and less tedious.

What I did: I added the “Jump to Content” anchor link you see at the top right of this page.

Proper Header Order
Correct usage of header tags (<h1>…<h2>…<h3>…etc) provides greater accessibility on a couple fronts. One, screen readers like JAWS offer a key command for reading off headers in order. They also announce the number of headers up front.

The WordPress template I’m using followed proper procedures like having only one <h1> tag, and subsequent <h2> and <h3> tags. However, there were a few instances, based on certain content showing in certain situations, where <h2> was missing. Skipping from an <h1> to an <h3> can cause confusion for screen reader users.

What I did: I straightened out some of the inconsistencies to ensure that on all pages of this site there is one <h1> followed by <h2>’s. I didn’t find the need to go beyond <h2>’s.

Link Focus
For those navigating through a site via a keyboard, making it obvious what link they are focused upon is good accessibility. The unformatted dotted-line box around the focused-upon link isn’t the most visually discernible, across the major browsers.

What I did: I chose a distinctive orange color to clearly denote what link you are focused on when you tab through the site.

a:focus, a:active {
text-decoration : none;
background: #ffce00;
}

Color Contrast
When you have text on top of a background image or solid background color, if there isn’t a strong enough contrast between the respective colors, certain visual disabilities such as color blindness may prevent users from properly differentiating the elements.

WCAG 2.0 call for a minimum contrast ratio of 4.5:1 (3:1 for large text).

What I did: Using an online contrast ratio calculator, I followed the most stringent Level AAA WCAG requirement by ensuring that my “the art of web accessibility” header text was at least a 7:1 ratio from the blue cloud background image.

Likewise, I made sure that my aforementioned link focus background color adhered to a 7:1 ratio from the text on top of it.

Ambiguous Linking
Last and certainly not least, the WordPress usage of “No Comments” or “X Comments” linkage for all blog posts is a link that provides no clear-cut direction as to where it will take the user. Links on the same page should also be worded uniquely and specific to the target.

When you see “No Comments”, you don’t intuitively know that clicking on it is your avenue to posting a comment on a specific topic, much less when there are 5 identical “No Comments” on the same page.

What I did: Given the handy code below, I changed the offending link in the Main Index Template so that, as you can now see on any post on this site, it reads something like “Comment on X topic”. That way, it is more obvious from the link that clicking on it takes you where you can post a comment on the specific post “X topic”.

<?php if('open' == $post->comment_status) : ?><p
class="comment_link"><?php comments_popup_link('Comment on
'.$post->post_title, '1 Comment on '.$post->post_title, '% Comments on
'.$post->post_title,'postcomment','Comments are off for
'.$post->post_title); ?></p><?php endif;?>

I made a few minor tweaks here and there, but these suggestions from GAWDS were very helpful and set me in a good direction for making this site closer to practicing what it preaches.

Tags: color contrast, gawds, guild of accessible web designers, h1, h2, h3, header tags, link focus, skip navigation, WCAG, Web Content Accessibility Guidelines, WordPress

I’m excited to say that today I was accepted into the Guild of Accessible Web Designers. Upon submission of my application, I received a number of suggestions on how to make the art of web accessibility more compliant with WCAG 2.0.

As I’ve mentioned, I knew when I went the content management system route that I was putting my accessibility, in part, in others’ hands….and I really appreciated getting some meaningful feedback from an accessibility expert. And again, to their credit, WordPress does seem to take accessibility seriously.

And so, I knocked out the problem areas (I may recap them in a future post) and my application was approved.

Though I still would rank myself as more of a novice in web accessibility, I’ve learned a ton in the past months. In the time to come, I’ll be learning a lot more!

Tags: gawds, guild of accessible web designers, WCAG, WordPress

This is the sort of headline that I particularly enjoy reading, given my recent focus on web accessibility – “2009: The year websites become accessible to all.”

Opera’s Bruce Lawson recently wrote an article for ZDNet UK discussing the prospects of web accessibility gaining prominence in 2009. He cites some key factors that are converging to paint a promising immediate future for the accessibility.

One, as we discussed in “Accessibility News: Web Content Accessibility Guidelines 2.0 Become W3C Recommendation“, the aged Web Content Accessibility Guidelines 1.0 were at least updated formally to 2.0.

Also, standards are expected to be pushed forward this year for Web Accessibility Initiative Accessible Rich Internet Applications — with its goal of Web content and Web applications that more accessible to those with disabilities.

Lawson cites as a factor the hot button issue of legal ramifications as well. Target having to settle out of court for its accessibility lawsuit certainly drew much attention. As as covered my last post, “Accessibility News: Expedia / Hotels.com make considerations for disabled travelers,” Expedia recently announced accessibility strides in response to a lawsuit.

Lawson points out that the British Standards Institution is fast at work on drafting a standard for website accessibility. Such a standard will carry a lot of weight on both sides of the pond.

Read Lawson’s article and his compelling points. Web accessibility has been around for years, but its undeniable that its importance and focus are only elevating.

Tags: aria, british standards institution, bruce lawson, bsi, lawsuits, opera, WCAG, web accessibility initiative accessible rich internet applications, Web Content Accessibility Guidelines, zdnet uk