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

Hi Alistair,

My comments are inline (labelled JR).

On 14/06/2010 10:11 AM, Alastair Campbell wrote:
> 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!)

JR: You're right - that doesn't sound reasonable!


> 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.

JR: The range of potential UI implementations makes this tricky to get 
right. The central point is that it should be easy for keyboard users to 
use the software for its purpose. Since this isn't very authoring tool 
specific, maybe we should leave it to:
A.1.1.1 Web-Based Accessible (WCAG Level A): Web-based authoring tool 
user interfaces conform to WCAG 2.0 Level A. (Level A)
AND
A.1.2.1 Non-Web-Based Accessible: Non-web-based authoring tool user 
interfaces follow accessibility standards and/or platform conventions 
that support accessibility. (Level A)

>
>      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/ )

JR: There are definitely more and less evolved checking systems and we 
try to feature more evolved ones in our "Implementing" document (e.g., 
http://www.w3.org/WAI/AU/2010/ED-IMPLEMENTING-ATAG20-20100420/#checking-types). 
But as a basic implementation to meet the requirement, I think 
checklists should be fine.

> 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"

JR: I agree that this is important. We've cover most of that here, 
except that ATAG generally avoids requirements to limit author choice:

B.3.1.1 Accessible Options Prominent (WCAG Level A): If authors are 
provided with a choice of authoring actions for achieving the same 
authoring outcome (e.g., styling text), then options that will result in 
web content conforming to WCAG 2.0 Level A are at least as prominent as 
options that will not. (Level A)

> 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

Cheers,
Jan
-- 
(Mr) Jan Richards, M.Sc.
jan.richards@utoronto.ca | 416-946-7060

Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto

Received on Monday, 14 June 2010 16:17:51 UTC