- From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
- Date: Mon, 31 Aug 2009 13:52:17 -0400
- To: Jan Richards <jan.richards@utoronto.ca>, w3c-wai-au@w3.org
As further clarification to the decision support proposal. Techniques to meet this success criteria would include any support that answers questions such as: - what are the accessibility implications of making this choice? - what will i need to do to make this technology/markup/element/component accessible? - what accessibility support does this technology/markup/element/component provide? In a Web App development toolkit this may be met by an indication of which components or component sets offered include ARIA markup. In a generic Web content development tool this may be met by indicating how captions can be included in Flash vs. Quicktime vs. Real etc. In a Wiki editing tool this may be met by indicating that the html based styling mechanisms are more accessible. etc. These advisories can be offered in the form of unobtrusive icons with links to further information or a dialog or in other ways appropriate to the look and feel of the interface. Jutta >Thanks Jan, > >The key thing I'm trying to get to is the preventative education or >guidance function - to inform, educate and guide an author using the >UI (as many people have said, most people don't read the >documentation) - so that they don't need to make a mistake before we >provide support in authoring accessibly. > >Like the apps I have pointed to, this would be light weight, in >keeping with the standard UI used by the tool. > >This would be pre-insertion when the author is making choices, and >is not necessarily to promote one choice over another but to give an >accessibility advisory about the choices available which can be very >subtle. > >Jutta > >At 3:54 PM -0400 8/24/09, Jan Richards wrote: >>Hi all, >> >>I just wanted to let people know I'm still trying to figure out out >>to word accessibility support (B.2.1.X Decision Support) in a >>testable way. >> >>One possibility might be to limit the scope to problems inherent >>with the content being inserted - not more holistic problems caused >>when the content is inserted (which would be better handled by a >>checker). >> >>And I'd also like to continue our practice of not dictating any >>particular workflow. >> >>If anyone has ideas, it would be great to hear them. >> >>Cheers, >>Jan >> >> >> >> >> >> >> >> >> >> >> >>Jutta Treviranus wrote: >>>In reviewing the state of Guideline B at the moment I have one >>>concern, we seem to have lost one important form of support for >>>creating accessible content. >>> >>>Originally we had the following abstract principles in part B: >>>1) if the tool makes decisions for the author, make sure those >>>decisions are accessible ones (automatic processes, automatically >>>generated content, etc.) >>>2) provide guidance, information and support to enable the author >>>to make *initial* decisions that lead to accessible content >>>3) enable the author to check that the content is accessible >>>4) enable the author to repair any content that is found not to be >>>accessible >>>5) make sure that this support is well integrated into the user >>>experience including the work flow >>> >>>We seem to have lost principle 2, the initial decision support. We >>>help the author check things once the decision is made, we help >>>them repair things when they have determined that they have made a >>>mistake, but we have no initial guidance or problem prevention - >>>to help them make the right decisions from the start or avoid >>>inaccessible choices. >>> >>>I therefore propose we include the following in B.2.1 - >>> >>>"B.2.1.X Provide Decision Support: If the authoring tool presents >>>choices to the author(s), provide information to assist the author >>>in making choices that enable the content to conform to WCAG 2.0. >>>(Level A) " >>> >>>We don't want to be prescriptive or didactic about how this is >>>done. The techniques document would list a range of techniques for >>>providing this decision support whether it is some way of >>>indicating which choices are accessible and which are not, or some >>>way of indicating the importance and priority of taking certain >>>steps from an accessibility perspective. >>> >>>Jutta >>> >> >>-- >>Jan Richards, M.Sc. >>User Interface Design Lead >>Adaptive Technology Resource Centre (ATRC) >>Faculty of Information >>University of Toronto >> >> Email: jan.richards@utoronto.ca >> Web: http://jan.atrc.utoronto.ca >> Phone: 416-946-7060 >> Fax: 416-971-2896 >
Received on Monday, 31 August 2009 17:52:57 UTC