Re: comments on ATAG2.0 B.1 Techniques - my action item

Finally finishing my comments...first part was sent here:
http://lists.w3.org/Archives/Public/w3c-wai-au/2009OctDec/0018.html

My comments below (I will try and put the changes in draft, marked as 
such before the next meeting):

Boland Jr., Frederick E. wrote:
 > Sorry the following is so “jumbled”..  won’t have much more time to
 > spend on it before the deadline..
 >
 > Best, Tim Boland NIST
 >
 > “immediately prior to” – difficult to determine – should be run often
 > before that point!

JR: How about "uses the accessibility checker, including a final check
prior to publishing"

 > “control every detail of” – should address accessibility specifically?

JR: suggest "authors to control every detail of the web content
produced, including following accessible authoring practices."

 > New technique – have authoring tool rate an authoring action by
 > producing “accessibility
 >  index” message (similar to “risk index” found in some antivirus
 >software?

JR: Needs discussion I think.

 > New technique – have authoring tool remember history of authoring
 > actions from author
 >  so that when authoring action is completed, dialog box/other prompt
 > will say “you’ve done this before, and here’s what happened..”

JR: Needs discussion I think.

 > New technique – when transforming/converting in same technology, have
 > “summary of current accessibility considerations” pop up before
 > transformation/conversion, and
 >   “possible accessibility impact – do you still want to continue? Yes
 >or no”  .. if yes “do you want to save summary of current accessibility
 > considerations for use later”?

JR: I like this.

 > New technique – after transformation/conversion complete, keep copy of
 > content before
 >  transformation along with accessibility considerations, and say “do
 > you want to go
 >  back to earlier transformation/accessibility – earlier point in
 > content” – and then click yes or no?

JR: OK

 > New technique – when authoring action attempted or content presented,
 > tool will present “these are some techniques you might use now” and 
then list some WCAG
 > techniques to use..?

JR: Needs discussion I think.

 > New technique – when transforming/converting between different
 > technologies, have tool
 >  prompt and say “here are some WCAG techniques to use in the new
 > technology?  Do you want to continue?  Yes or no”

JR: Needs discussion I think.

 > New technique – when transforming/converting between different
 > technologies, have tool
 >  prompt and say “these WCAG techniques in new technology may be
 > equivalent to techniques
 >  used in old technology – do you want to continue – and say yes or 
no?

JR: Needs discussion I think.

 > Current techniques presented are OK but very general and need to be
 > more  specific – refer
 >  to specific WCAG techniques or WCAG techniques grouped by technology?

JR: Under related resources?

 > Why is the distinction made between authors and end users in B.1.2.1?

JR: Because authoring tools often give better access to things like
comments.

 > What is definition of “similar data structure”?

JR: I'm hoping it's clear from the examples below.

 > What are “presentation conventions”?    Why is “presentation”
 > converted into “markup”?
 >  I thought presentation was to be kept separate from markup?

JR: That one could be removed.

 > What is definition of “end product”?

JR: We say "in the end product of the transformation or conversion".

 > New technique – authoring tool prompts author as to “which version of
 > content do you
 >  want to access” – and list all the versions from beginning to
 > present?

JR: Needs discussion I think.

 > New technique – when content proposed for deletion from current
 > editing view, tool always
 >  saves content as backup to be retrieved later?

JR: Assume this is for B.1.2.4...retrieval is not mentionned in the SC.

 > New technique – in automatic generation of content from authoring
 > tool, documentation of
 > how that content meets WCAG2 is provided also, or list of WCAG2
 > techniques used is provided also?

JR: B.1.3.1-OK

 > New technique – for content creation using a technology contained in
 > WCAG2 techniques
 >  document, authoring tool first displays a list of those techniques to
 > the author, and
 >  then the author can select which ones they want to use?

JR: B.1.3.1-Needs discussion I think.

 > New technique – for any authoring action, authoring tool suggests
 > general techniques
 >  from WCAG2 techniques document, and then asks author if author wants
 > to use any of these in content creation?

JR: For any authoring action? General comment: I think we want to be 
careful to not imply that user's are primarily seeking to create 
accessible content. Primarily they are seeking to author some content, 
accessibility would be a secondary concern, like correct spelling.

 > NOTE: “accessibility information” should refer to the way in which a
 > technology is used
 > to promote accessibility – in keeping with thought that technology
 > itself is not
 > accessible or inaccessible, but that a technology may be used in an
 > accessible or inaccessible manner

JR: I think the defn is clear that accessibility information is a bit 
more abstract than the technology.

 > Need to specifically reference WCAG techniques document - perhaps
 > under "related resources"

JR: I'll make sure this is done whenever WCAG 2.0 is mentionned.

 > tools should encourage use of WCAG techniques where appropriate - tool
 > should be knowledgable of WCAG
 > techniques - tool should be able to present selected WCAG techniques
 > and issues with them when prompted - also issues with SCs?

JR: Not sure what you mean.

 > need to distinguish transformation/conversion in one technology from
 > those between technologies - in the latter
 > case, may not be able to preserve accessibility information by default

JR: I think the concern is relevant to transformations and conversions 
...e.g., tables hold structural info that is not fully captured in 
linearized text.

 > should say "authors with disabilities" - "support" is ambiguous - not
 > testable?

JR: Do you mean here? "PRINCIPLE B.2: Authors must be supported in the 
production of accessible content"...I think it is fine...we mean support 
all authors and the principle wording itself is non-normative.

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 Tuesday, 3 November 2009 19:02:54 UTC