RE: (Important) AUWG Teleconference on 14 June 2010 4:00pm-5pm ET

Hi Jan,

Apologies, but I can't find a reasonable phone system to use this evening. 
(£1.25/MB for an hour Skype call isn't quite reasonable for me!) 

I've read through the changes, and they were all fine, but I do have two suggestions that build on the previous discussion:

    Removing A.3.1.3 Keyboard shortcuts are provided. 
I agree with not requiring keyboard shortcuts, but is there anything that makes sense to add that fulfils that goal? Something equivalent to WCAG2's 2.4.1 bypass blocks for authoring tools.

For a web based CMS that included WYSIWYG editing, I would want to require some kind of function for allowing quick access to editing menus and the editing area. That could take several forms, such as links with keyboard shortcuts, ARIA landmark roles, context menus or even just structure elements (such as headings).

I'm not sure what would make sense from a desktop application point of view though?

As an initial stab, perhaps something like:
"A.3.4.3 Provide a mechanism for keyboard users to navigate to editing areas and menus."

I was thinking about 'key areas of the interface', or 'common functions', but the common issue is usually the manipulation of the content by separate interface elements.

    Rewording: B.2.2.1 Check Accessibility:
I agree in terms of the text for that checkpoint, but I do wonder if there is something we can do to prevent the checklist mentality? (This is worth reading for background: http://www.rebuildingtheweb.com/en/checklist-accessibility-harmful/ )

The ideal thought-process I'd like vendors to go through is:
1. How can we help authors by preventing them from creating/adding inaccessible content?
2. If we can't prevent it, how can we help authors work out what the issues might be?

It is entirely possible that we can't write normative text for this that applies across different situations; but as an example how does this sound?
"B.2.1.4 Default to accessible options: The default authoring controls support authors creating accessible content. (Level AA)
  Note: Where an authoring tool prevents users from creating inaccessible content (e.g. removing colour-pickers in favour of pre-defined styles), the authoring tool does not have to implement an associated check for B.2.2.1"

My intent is to make it clear that authoring tools should *prevent* accessibility issues where possible, rather than overwhelm authors with checks. 

If I can find a phone I can use I'll dial in, but if not I'll catchup with the notes tomorrow morning.

Kind regards,

-Alastair

Received on Monday, 14 June 2010 14:12:32 UTC