Re: start on my AUWG techniques review action item

Hi,

Thanks a lot for the thorough comments. My comments are marked with JR.

Boland Jr., Frederick E. wrote:
> This is what I have so far..  First general/meta comments on Techniques 
> Document as a whole
> 
>  and then more specific comments on each checkpoint I was assigned.. 
> sorry it’s a little rough
>  
> 
> General
>  
> 
> Meta comment - Introduction section needs to be "beefed up" to encourage 
> submission of ATAG
>  techniques (maybe even provide a mechanism, like the WCAG techniques 
> submission form?),
>  and to give more information on how to interpret the intent and 
> examples following. 

JR: OK

> Also Introduction seems inconsistent with following text in SC sections 
> - text says examples
>  meet SCs, but Introduction seems to imply that examples alone are not 
> sufficient
> (may be confusing - if one example for an SC is successfully 
> demonstrated, is that SC
>  satisfied and can just stop there)?   How does one measure that an 
> example is successfully
>  demonstrated?   Also where are the actual techniques - I just notice 
> intent and examples

JR: I suggest:
(1) we look at changing the name of the document to "Understanding ATAG 2.0"
(2) We say "Examples of Success Criterion x.y.z" rather than "Examples 
that meet the Success Criterion"

>  under each technique section (may be confusing, at least when 
> considering different WCAG
>  format also (reason for different format from WCAG techniques should be 
> documented? -
> otherwise may not look good to outsiders)..  reference from Guidelines 
> also is out of date -
> talks about "advisory" and "sufficient"?   

JR: OK


> Meta comment - do we want to adopt some of the ideas (if not the 
> style/format) of WCAG techniques
>  (applicability, description, examples, resources, related techniques, 
> tests)?
>   Do we want to include test procedure to determine if example/technique 
> successfully
>  meets the SC or is successfully demonstrated?

JR: I just can't imagine doing this in a comprehensive way that covers 
all of the outputted technologies and tool types that ATAG 2.0 applies to.

> Why do we call items "examples" instead of "techniques"?
> 
> What about other "techniques" besides those listed?   Do we give 
> encouragement to submitters
>  to submit additional techniques (or examples), to foster innovation and 
> creativity?  
> If so, how would they do it?

JR: In the "Introduction" paragraph we say this but we could say it more 
loudly.


> How is it determined how a particular example "meets" a success 
> criterion?  Is it the opinion
>  of the AUWG?  Other means?  Need some measure to determine how 
> technique meets SC, and
>  documentation as to why that example meets SC if we believe it does.. 
> and how example is
> successfully demonstrated..

JR: I've suggested a wording change above. But yes, I would expect that 
the group would only include an example of something it thought met or 
substantially contributed to meeting the success criterion.


> How is "intent" different from "rationale" in Guidelines (may be confusing)?

JR: Agreed. We could rename the rationales as "Intent of the Guideline"? 
Now that the techniques are updated we might also move this text to the 
Techniques doc from the Guidelines doc.

> Meta comment - are the ATAG Guidelines and Techniques accessible or can 
> be authored accessibly
>  (follow our own guidelines and practices)?

JR: The documents are accessible and will certainly be given an 
accessibility check-over before final publishing.


> re: Related Resources:  is there a requirement about what qualifies as a 
> related resource? 

JR: No.

> Do the related resources imply endorsement/vetting by the AUWG (maybe a 
> disclaimer needed)?

JR: Let's use the WCAG 2.0 disclaimer: "Resources are for information 
purposes only, no endorsement implied."

>  There are a lot of resources out there, of varying degrees of quality, 
> and some are company-
> specific (would EOWG help?)

JR: We could ask.

> One possible resource for A.4.1 - WCAG Checkpoint 3.3 and associated 
> material

JR: Good idea.

> Possible Resources for A.4.2 - lots of links to writing good software 
> documentation,
> for example wikipedia:
> http://en.wikipedia.org/wiki/Software_documentation

JR: Good idea.

> (PS - I think "documentation" is too loose - there can be good, bad, and 
> confusing documentation -
>  we should strive to provide relevant and useful
> documentation, and ask author to evaluate same)

JR: OK


> Specific Comments re:A.4.2.1
> 
> re: intent - say "authors with disabilities" instead of just "authors" - 
> say "instruction
>  for such use" instead of just "instruction"?

JR: OK

> re: example - is the help system (and "accessibility features" section) 
> accessible and
>  immediately available to authors?  Is it linked directly at many places 
> in the authoring tool?
> Does it actually provide meaningful help?

JR: We could work that text in.

> say "specific" in front of documentation - documentation should be 
> helpful also, with
> illustrations/examples to guide..
> 
> - also have item saying to author "was this helpful?  If not go .." in list
> say "specifically.." in front of every item

JR: Seems wordy to add it for each

> new example - have a notification saying "do you want help on these 
> topics?" and then enter "yes"
> or "no" ..?

JR: OK

> new example - have a search help feature where an author could enter 
> text for assistance..?

JR: Like a search text box?


> Specific Comments re: A.4.2.2
> 
> Say "authors with disabilities" instead of just "authors"  - say 
> "instructions that provide
>  such support" instead of only "instructions"?

JR: OK

> "documented" -  a written or printed paper furnishing information or 
> evidence, also a "data file"
> (definition from dictionary.com) - is our text faithful to this definition?

JR: I think our def'n is good:
http://www.w3.org/WAI/AU/2009/ED-ATAG20-TECHS-20090909/#def-Documentation


> say "accessible documentation" - how is documentation presented - is it 
> presented accessibly?

JR: I think A.1 covers this. Otherwise we'll have to say "accessible" in 
front of everything we say.

> new example - user guide or help menu that is accessible and usable 
> (accessed at any point
>  with simple action)?
> 
>  
> 
> needs to be more than "documented" - documentation must be helpful and 
> relevant - more specifically -
> how is it documented - what is association with feature?  (for instance, 
> accessible dialog box,
>  menu item, prompt, with examples/illustrations?)

JR: OK


> Specific Comments re: A.4.1.1
> 
> re: intent - how are those with disabilities more disadvantaged than 
> others in avoiding
> mistakes with authoring actions?

JR: It's in the rationale but I could say it again.

> typos - non-web-based..  "action" is listed twice
>         - web-based - "editing" instead of "ending"?

JR: OK

> new example - have a confirmation notification with "undo" saying "do 
> you really want to
>  undo previous action?" to avoid pressing "undo" accidentally (for use 
> in non-web-based and
> text edit field of web-based..)?

JR: OK


> new example - accessible dialog box/menu item appears when authoring 
> action requested stating
>  that  "warning - action is irreversible - do you still want to 
> proceed?.. and then click
>  "yes" or "no" ?

JR: OK

> A.4.1.2
> re: intent - how are those with disabilities more disadvantaged than 
> others in being able to
>  modify settings without making mistakes?

JR: Same reason from rationale.

> new example - in preference setting utility, when adjusting setting, 
> dialog box/menu item
>  says "result of setting change will be.. do you still want to do 
> this?.. and then click "yes"
>  or "no"? 

JR: OK

> new example - "restore default setting" actionable item should always be 
> available and then
> say what that default setting is, for the author to activate if 
> necessary..?

JR: OK


> new example - dialog box/menu item appears when preference setting is 
> changed saying
> "warning - this change is irreversible - do you still want to do this?" 
> - and then
> click "yes" or "no"?

JR: OK


> A.4.1.3
> 
> re: intent - how are those with disabilities more disadvantaged than 
> others in being
>  immediately able to reverse "undo" - also should say at end of 
> sentence.. "by authors with
>  disabilities"

JR: Same reason from rationale and OK.
> 
> new example - have a confirmation notification with "redo" saying "this 
> action will reverse
> 
> (cancel) undo - do you still want to do this? .. and select "yes" or 
> "no" (for web-based)?

JR: Overkill I think. Better to say can undo, redo back and forth.

> new example - for text-based entry, have "redo" option after "erase 
> content" which brings
> back the content previously erased?

JR: Maybe overkill?

> new example - after "cancel", can display message "do you want to undo 
> cancel"?  and then
>  select "yes" or "no"; or alternately, have "cancel with redo" and 
> "cancel without redo"
> options..?

JR: Maybe overkill?

> new example - non-web-based - have redo option appear if undo is 
> confirmed as previous
>  action..?

JR: OK



Cheers,
Jan


-- 
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, 14 September 2009 17:49:19 UTC