W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 2010

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

From: Ronksley, Andrew <Andrew.Ronksley@rnib.org.uk>
Date: Mon, 14 Jun 2010 16:31:56 +0100
Message-ID: <A3C7B6DEAA620B4D8A229396978A584902F4FA88@jstmsx02.ads.rnib.org.uk>
To: "WAI-AUWG List" <w3c-wai-au@w3.org>
Hi Jan.

Unfortunately I won't be able to dial in today either. I'm fine with the proposed changes however, but I agree with Alastair in that we should explore a mechanism for accessing menus and edit areas etc for web based applications.

This week, I can outline some of the work we've done at the RNIB to facilitate keyboard access in our rich text editor in SharePoint. Apologies but I don't have time to describe this just now before the call today.


-----Original Message-----
From: w3c-wai-au-request@w3.org [mailto:w3c-wai-au-request@w3.org] On Behalf Of Alastair Campbell
Sent: 14 June 2010 15:12
Subject: 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,


 To report this e-mail as Spam, please forward it to:  spam@mailcontrol.com


NOTICE: The information contained in this email and any attachments is 
confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of the 
content of it or of any attachment; you are requested to notify the 
sender immediately of your receipt of the email and then to delete it 
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants.  However, it 
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and 
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227

Website: http://www.rnib.org.uk

This message has been scanned for viruses by Websense Hosted Security - 
Received on Monday, 14 June 2010 15:32:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:58 UTC