About Steve Faulkner

Steve is the Technical Director at TPG. He joined The Paciello Group in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. He is the creator and lead developer of the Web Accessibility Toolbar accessibility testing tool. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including HTML 5.1, ARIA in HTML, Notes on Using ARIA in HTML and HTML5: Techniques for providing useful text alternatives. He also develops and maintains HTML5accessibility.

Comments

  1. What worries me about ARIA is developers who think they can just insert it on top of an existing and largely inaccessible web applications and that it will just work. We need to remember, the browsers that support ARIA are Firefox, Opera and maybe Internet Explorer 8. None of these are mainstream browsers used by people using screenreaders, and I don’t see this drastically changing any time soon.

    True, some screen reader users have Firefox installed, but this tends to be developers or consultants that have it installed for testing purposes or as a lesser-used alternative, not the typical audience that would benefit from ARIA support.

    The accessibility improvements offered by ARIA are very much welcome, but its not a full solution now, it may actually take years – at least until IE8 is the dominant browser talking to screenreaders, for it to be the main approach to building an accessible website.

    I have to admit, on hearing that Yahoo! Mail were using ARIA I was very sceptical. The presentation has confirmed that just whacking ARIA ontop doesn’t solve all the problems even in a controlled test environment and a “preferred” browser, let alone the typical browsers being used by screen reader users.

    Again, ARIA offers so much promise, its worthy of our support. But, it needs to be used in an appropriate way, as part of an end-to-end solution. And that solution is building web applications in an accessible way from the start in a layered way, and using ARIA to greatly enhance the user experience for people who are using the Firefoxes, Operas and IE8s and the range of screenreaders that support ARIA.

    I’m actually talking about progressive enhancement for accessibility – the concept behind progressive enhancement is right, and at this point in time the idea of progressively enhancing accessibility is no longer a ludicrous or oxymoronic idea. And that brings a smile.

    Mike.

  2. I completely agree with everything you say Mike, and I definitely don’t
    consider myself a developer who thinks ARIA can just be added as a
    miracle cure to make any project accessible. It’s common knowledge that
    any effort towards an accessible result is most successful in every way
    when applied from the start of the project’s live cycle. However, most
    people here will also agree that this is not always feasible, and that a
    lot of external factors (company politics, available resources, etc.)
    are of influence.

    At the time (and now still), there was a big demand for real-life use
    cases for ARIA on a large, commercial scale. We took the challenge,
    knowing this wouldn’t be a clean ‘accessible from the ground up’ deal,
    but rather an interesting experiment to gain more insight about
    implementing ARIA in a commercial context. To truly implement
    progressive enhancement in Yahoo Mail would mean starting from scratch,
    which was not an option.

    The unfortunate reality is that a lot of ARIA will have to be
    implemented in projects like these in the future as well, and although I
    applaud all the DOJO’s, YUI’s and MDCs and UIUC’s out there, we need to
    learn from these gritty experiences too.

  3. Hi Hans, thanks for the comments. It is great that ARIA was tried out, and the results made public in this way. Thank you for your efforts to get that done. I think the presentation reflects the truth about web accessibility – it needs to be done properly from the ground up. Hopefully people will learn from what’s been done in Yahoo! Mail, and realise that there isn’t a quick fix.

    I admit, I didn’t see the point of adding ARIA to Yahoo! Mail, and you’ve outlined the reasons very clearly in your comment: “At the time (and now still), there was a big demand for real-life use
    cases for ARIA on a large, commercial scale.” That’s realistic and relevant, and you’ve achieved it with this presentation.

    I think the main takeaway – using ARIA in YUI components where they can be rebuilt properly from scratch is a good start.

  4. Although the actual problems you had are not listed I absolutely agree it is not as simple as just adding ARIA. Here are just a few issues a developer will experience when converting your Web 2.0 application over to supporting WAI-ARIA:

    – If you have a tab-based keyboard navigation implementation to meet WCAG 1.0 this is a problem. Developers incorrectly use links to make widgets focusable. This is not something the author would have wanted in the first place and the author was forced to something that met compliance but was not that usable. So, a switch of your application to one that uses tabbing to get to significant widgets and the use of the arrow keys navigate within the widget to elements like divs will require a redesign. That said, you will have a more usable solution in the end.

    – The current ATs don’t hold you in ARIA “application” mode. Small page updates can throw you out. This is extremely frustrating for the developer and the end user. I will point out that this is only a transitional problem. IBM is working with key ATVs off-line to help ATs redefine how they interact with a dynamic web page to produce a more usable solution. Unfortunately, those changes have not made their way out to the developer community yet.

    – The accessibility of Web 2.0 applications is dependent on the ability to convey contextual information. Document structure is very important in providing this. ARIA allows you to surpass some of this using the owns and flowsto relationships along with properties like posinset, setsize, and level. This is a new level of understanding wrt. accessibility that many developers are not conditioned for. WCAG 1.0 was so simple that people became accessibility experts without truly understanding AT interoperability. For things that were too hard to deal with (JavaScript and CSS) it told you to disable them in the browser and still run.

    I agree with the previous post that it will be best to focus on the accessibility of a core set of widgets using ARIA and then redistribute them for reuse throughout a company. This is IBM’s approach with Dojo. It is not just a matter of implementing ARIA but it is also a matter of knowing how to create a rich internet application. Your technical knowledge of web development must be much stronger. The best strategy to addressing this would be to have skilled developers work on a core set of widgets and then deploy them for reuse. A similar strategy is being targeted at the fluid project (http://www.fluidproject.org).

    We are an industry in transition. We need to approach accessibility differently as well. … Much like you would on a desktop application.

Comments for this post are closed.