Re: ATAG 2 comments

Hi all,

I'm glad to see comments starting to roll in! Here are some thoughts on 
this one:

On 14/07/2010 9:25 PM, James Craig wrote:
>
>> A.2.3.1 Independence of Display: Authors can set their own display settings for editing views (including WYSIWYG views) without affecting the web content to be published. (Level A) [Implementing A.2.3.1]
>
> This statement seems contradictory. A personalized view for the authoring tool that displays content differently from the the view to be published, by definition, CANNOT be considered WYSIWYG. I also believe this requirement puts undue burden on the user interface design of the authoring tool, because it's difficult for a simple, usable UI to accurately convey that this-is-your-own-view-of-the-content-but-its-not-the-same-as-what-will-be-published… WYSINRWYG: What you see is not really what you get.
>
> I don't agree that this is necessary, and I'd recommend downgrading this from a Level A requirement to a Level AAA suggestion.
>
> Perhaps this could be changed to remove the confusing reference to WYSIWYG: "Authors can set their own display settings for alternate editing views without affecting the web content to be published." If that change were made, I could accept this as a Level A requirement.

JR: I agree that "(including WYSIWYG views)" might be confusing (and 
could be removed). Perhaps instead we discuss the situation in the 
Implementing 2.0 doc. Essentially, WYSIWYG is a bit of a misnomer 
because the end-user can quite often modify what they get. We just want 
to say that the author should similarly be able to modify what THEY get 
as they author the content.


>> A.3.1.1 Keyboard Access (Minimum): All functionality of the authoring tool is operable through a keyboard interface, except where editing web content properties that encode continuous input. (Level A) [Implementing A.3.1.1]
>
> Please change "Keyboard Access" to "Keyboard Equivalent Access" and change "keyboard interface" to "keyboard equivalent interface."
>
> For example, all functionality of iOS and accessible iOS applications is available through a keyboard equivalent and is accessible through multi-sensory output (sight and sound, and touch if using a external braille display), and does not require a standard keyboard interface to be accessible.
>
> Example: See Victor Tsaran's demo of iPhone4/iOS4 with an external braille display.
> http://www.youtube.com/watch?v=6_TFHqIHBqM

JR: I agree and this probably deserves an example in the Implementing 
ATAG 2.0 doc.

>> A.3.2.2 Timing Adjustable: If a time limit is set by the authoring tool, then at least one of the following is true: (Level A) [Implementing A.3.2.2]
>> …
>> (f) 20 Hour Exception: The time limit is longer than 20 hours.
>
> Minor: I'm pretty sure the 508 refresh requires 8 hours for the exception, not 20. If you have a good reason to refute 508, please file a comment on that requirement. Otherwise, I'd suggest remaining consistent and using the 8 hour exception.

JR: We're not refuting but rather remaining consistent with WCAG 2.0. 
Frankly, the number is pretty arbitrary either way. This requires 
discussion.

Cheers,
Jan



>
>
> Cheers.
>
>

-- 
(Mr) Jan Richards, M.Sc.
jan.richards@utoronto.ca | 416-946-7060
Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto

--
NEW CONTACT INFORMATION:
On August 1st, the ATRC is moving to OCAD University
to become the Inclusive Design Research Centre.

My new email address will be:
   jrichards@ocad.ca

Received on Friday, 16 July 2010 03:37:46 UTC