Why UAAG needs you (oh no not another set of guidelines)

With just under two weeks to go until the call to review the User Agent Accessibility Guidelines 2.0 (UAAG) closes (April 22nd) I expect you’re all heads down going through the spec like things demented…ok, possibly not.

Working for Opera I’ve just joined the UAAG Working Group and have started to look at the guidelines properly for the first time in ages. This is not my natural area as I’m a content person through and though and therefore much more familiar with the Web Content Accessibility Guidelines (WCAG). So it’s got me thinking would a developer, a website owner, a user or a software procurement person really want to get their hands dirty with UAAG?

So this is what I came up with that made sense to me:

  1. You develop accessible content. UAAG is just one of three sets of guidelines relating to accessibility produced by the W3C the other two being the “celebrity” Web Content Accessibility Guidelines (WCAG) and the more “D-List” (but up and coming thanks to social networking) Authoring Tool Accessibility Guidelines (ATAG). All share interdependencies and are designed to work together so that browsers (UAAG) render content (WCAG) that has been authored and tested (ATAG) for accessibility.
    If one component is weak it can result in your content (that you have made accessible according to WCAG say) unusable. Think for example of the amount of times you hear “But this browser works differently from that browser” or “screen readers haven’t caught up yet and can’t handle such and such”. As a developer you have to spend more time developing workarounds to compensate for the browser and/or assistive technology. Not something that anyone relishes.
  2. You’re interested in developments with HTML5. With so much discussion around what is relevant to the browser implementors and authors it’s useful to see where the lines blur between browsers and authors. HTML5 is attempting to do much that the author has had to do themselves before such as forms validation, support for video and audio, datagrids and so on. Previously these would be done by the authors using scripts meaning more work and less consistency for the user across websites. This is turn leads to a wider margin for error to allow inaccessible content and poor usability.
  3. You build plugins or extensions. According to the UAAG FAQ these too are also user agents and therefore have to follow the principles of keyboard access, rendering content accessibly and communicating with assistive technologies. So if you’re into building extensions for Firefox then you’ll need to ensure accessibility.
  4. You develop web applications. Ok, so this is more of a controversial one but there’s nothing wrong with that. I’m also curious to hear what people think. So here’s the question: when does web content morph into being a web application and become better defined as a user agent rather than web content? For example, Easy YouTube is a skin for YouTube designed to make playing video easier for people with cognitive problems. As such it can also be defined as a media player which sits very much under the user agent definition.
    This is a tricky because it’s doubtful that any developer is going to seriously look at following both WCAG and UAAG when developing. You can also argue that if you were able to upload, and therefore author, content to Easy YouTube the developer could find themselves having to reference UAAG, WCAG and ATAG.
    Back in the real world I think this is asking way too much but there is something of a cross over. It may be that WCAG is sufficient covering key aspects such as device independence and keyboard access but understanding the relationship would be useful. I wonder if anyone has done a mapping of UAAG, WCAG or ATAG…
    The UAAG working draft does specifically ask what people’s thoughts are on web applications:

    “Does the inclusion of Web applications (e.g video players, email clients, document applications) in the definition of user agents add undo burden or conflicts? What distinguishes Web application user agents from Web applications that are not user agents?”

    So leave a comment if you have any thoughts.

  5. You’re a user. Being a user of assistive technology I would be keen to ensure that content worked for me. Understanding all three sets of guidelines means you’ve got a better idea of why something doesn’t work and how it can be fixed. This will help you to both flag problems to the vendors of user agents as well as inform decision as to which browser, media player and assistive technology you use.
  6. You’re in procurement. If you are someone who makes decisions about what software to purchase you’ll need to know which software meets you accessibility requirements. Being able to do a comparison against UAAG, or to be able to ask for compliance to UAAG in tenders can help safeguard accessibility concerns.

So I’m sure you’re all convinced that you need to look at UAAG right away so I wont hold you back with any more chatter from me. Details about how you can comment on UAAG are available from W3C together with an overview of UAAG and the draft UAAG 2.0 in all its glory.