Re: Additional IBM ATAG 2.0 comments

Thanks Barry,

I have added these comments to the comment table at:

http://www.w3.org/WAI/AU/2007/atag20_pubWD_7dec2006_comment_responses.html

Cheers,
Jan






Barry Feigenbaum wrote:
> 
> *More input from IBM accessibility folks:*
> 
> 
> *From Shannon Rapuano*
> 
> Review of Part A which focuses on accessibility of the tool:
> A.1.2.  Why isnt' synchronized alternative for MM considered P1 
> consistent with WCAG?
> 
> A.2.1.  Keyboard access.  I do not agree with the success criteria that 
> requires single key or key + modifier access to the listed functions. 
>  This is not P1.  Access to the function with the keyboard is P1. 
>  Specifying single key or key+ modifier is at most P2 since this is 
> usable access and not accessibility.
> 
> A.2.8.  Having multiple sets of preferences and settings should be P3 
> and not P2.
> 
> 
> Review of Part B which focuses on output of authoring tool:
> 
> B.2.4.  I am concerned about the testability of this checkpoint.  I 
> think providing text equivalents for non-text content is Priority 1, but 
> assisting the authors to ensure the alternative is "accurate and fits 
> the content" is Priority 2 at best.  It is not a Priority 1 requirement.
> 
> B.2.6.  Is there a reason why the group made providing a summary of 
> accessibility status a P3?  I would view this as P2 given the other 
> requirements.
> 
> B.2.7.  There should be a definition of "tutorial" for "Provide a 
> tutorial on the process of accessible authoring."  The success criteria 
> is clear that the tutorial is specific to the tool, but the language of 
> the checkpoint leaves it open to interpretation.  Also, how is B.2.7 
> different than B.3.5. to document accessibility features of the tool? 
>  What specifically is different about a "tutorial"?  
> 
> B.3.1 and B.3.3.  I am concerned about the testability of "prominence" 
> to meet these checkpoints.  I suppose it is vague enough that we could 
> justify meeting the criteria in our tools.
> 
> 
> *From Cori Ryan*
> 
> 
> So my feedback is that the/ Definition of Authoring Tool/ should extend 
> to include a bullet on that describe tools like Rational manual tester 
> that generate web content as an Export feature.  This is a case that can 
> be easily overlooked.
> 
> I can exemplify with a basic example of images:
> 
>     * have the ability to provide alt text to images they paste in the
>       script in the RTE and that alt text must carry though on export.
>        This is likely the same text that should be supplied for the MSAA
>       Name value.
> 
> 
> 
> 
> *From Rich Schwerdtfeger*
> 
> 
> Comments on Section 2.2 Conformance claims. I think the concept of 
> Baselines should be introduced here as it is appropriate. Is WCAG 
> Benchmark a new name for Baseline?
> 
> Also, the document seems to have blurred Part A and Part B here when the 
> intent was to be separated.
> 
> A.0.1 There needs to be a discussion of the Benchmark or Baseline.
> 
> A.1 Text Alternatives should include short and long desriptions(help 
> text) for non-text object. ODF and HTML both provide for these. Also 
> ARIA has an aaa:describedby property toreference the long description.
> 
> A.1.3  ... If the visual display (e.g., fonts, sizes, colors, spacing, 
> positioning) is controlled by the authoring tool rather than by the 
> _platform_ <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-platform>, 
> then the authoring tool /must/ provide at least the same configurable 
> properties with at least the same configuration ranges as the platform. 
> Someone should make a request that UAAG follow a similar requirement. 
> This is not specific to an authoring tool.
> 
> A.2.1 Requiring single-key modifiers should be a P2. Also, drag and drop 
> and in-context menus should fall under this section.
> 
> A.2.1 Should be synched with UAAG.
> 
>       A.2.8 Should be P3
> 
>       A.4.1 Has the group thought about keyboard conflicts with 
> assistive technologies? ATs can change their UI regularly so conflicts 
> can arise and it would be difficult to mandate that no kbd. conflicts 
> should occur. However, they are source of contention.
> 
>       B.1.1 Back to benchmarks and baselines. The baseline should be 
> explicit stated.
> 
>       B.1.2 the _accessibility information_ 
> <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-Accessibility-Information> 
> is available to _end users_ 
> <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-End-Users> in the 
> result of the _transformation_ 
> <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-Transformation> or 
> _conversion_ 
> <http://www.w3.org/TR/2006/WD-ATAG20-20061207/#def-Conversion-Tool>, or 
>   ... I would use the words "preserved for" vs. "available to"  and I 
> would add that this should only be done if the target content-type 
> supports the accessibility information. For example, ODF supports 
> headers in rich text editor tables whereas MS Office does not. Also long 
> description and short text alternatives are provided in ODF whereas MS 
> Office only provides one text alternative.
> 
>       B.1 3 Will the techniques show how this is done through the 
> accessibility api?
> 
>       B.2.1 I am a bit confused about relative priority. While I 
> understand that this is relative to WCAG priority levels, ... Is the 
> ATAG priority for a P1 to prompt for accessibility information defined 
> in a P1 check point in WCAG? When there is dynamic content and states 
> and properties are changed in ARIA, you should define techniques that 
> show how the browser will display accessibility api state or property 
> change event notifications
> 
>       B.2.2  Success Criteria 2 should not be limited to the element 
> type. The author may place an ARIA role on the element which redefines 
> what states and properties it should support. ATAG should allow for a 
> comparison of the states/properties set with the states and properties 
> allowed for that role type. For example, IBM has a tool called RAVEn 
> which will compare this information against the states and properties 
> defined for a role in the Role taxonomy.
> 
>       B.2.6 I agree this should be a P3. It will be difficult to do this 
> for dynamic content unless it were a snapshot in time.
> 
> B.3 This section should provide information to the author in the case of 
> a model-based authoring tool about whether reusable objects have 
> previously been tested for accessibility with assistive technologies. 
> This would help promote accessibility solution construction and perhaps 
> reduce the load on the developer.
> 
> 
> 
> Barry A. Feigenbaum, Ph. D.
> Tool Architect
> Human Ability and Accessibility Center - IBM Research
> www.ibm.com/able, w3.ibm.com/able
> voice 512-838-4763/tl678-4763
> fax 512-838-9367/0330
> cell 512-799-9182
> feigenba@us.ibm.com
> Mailstop 904/5F-021
> 11400 Burnet Rd., Austin TX 78758
> 
> Accessibility ARB Representative on SWG ARB
> W3C AUWG Representative
> Austin IBM Club BoD
> Interface Technologies IDT Member
> QSE Development TopGun
> 
> Sun Certified Java Programmer, Developer & Architect
> IBM Certified XML Developer; OOAD w/UML
> 
> This message sent with 100% recycled electrons

-- 
Jan Richards, M.Sc.
User Interface Design Specialist
Adaptive Technology Resource Centre (ATRC)
Faculty of Information Studies
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, 13 February 2007 20:54:13 UTC