Re: Call for Review: Authoring Tool Accessibility Guidelines 2.0 Working Draft

My initial thoughts on these comments...

Li, Alex wrote:
> 
> A.1.3 SC1--"...authoring tool/ must/ provide at least the same 
> configurable properties with at least the same configuration ranges as 
> the platform."  I don't think that can be confirmed one way or the other 
> unless the method of configuration between the authoring tool and the 
> platform are exactly the same.  They are usually not the same.  That’s 
> goes the same with audio for part 2. You should also consider that 
> authoring tools can provide additional configuration option "on-top-of" 
> the platform.  Thus, the authoring tools may extend the configuation 
> options, even though its range may appear lesser than that of the platform.


JR: Maybe we could go back to being more specific. Maybe rewording as: 
SC: The authoring tool must allow the author to specify font family, 
text scale, foreground color, background color, magnification (e.g. for 
graphics and spacing between text) by one of the following methods: (1) 
inherit these settings from the platform, or (2) include these settings 
within the authoring tool's own preferences with the same 
configurability range as the platform.


> A.2.1 Should add an exception for analog, time-dependent input as in 
> WCAG 2.0 2.1.1


JR: Good idea to look at "analog, time-dependent input".


> A.2.1 Success Criteria 5 is a convenient feature, but should not be 
> priority 1.  As long as user/author can use keyboard to activate the 
> settings, it is accessible.


JR: I don't think I agree - if I set up different control keys etc. I 
would expect them to be saved.


> A.2.3 Success Criteria 1.  The SC statement draw out a condition of what 
> is needed when time limit is not controlled by time-sensitive external 
> constraints.  But it says nothing about conditions where the time limit 
> is controlled by external constraints.  How are the authoring tools, or 
> more appropriately the authoring environments, where time contraints are 
> controlled by external contraints to fulfill this priority 1 
> requirement?  You need to make an explicit exception statement here or 
> have instruction of what needs to be done.  As you should know, almost 
> all commercial products are made in collaborative environments where 
> such external time contraints are essential.


JR: Maybe we need a new SC dealing with this since clearly connect 
time-outs are different from the actions of collaborative authors.


> A.2.5 That is a usability feature.  It impacts people without 
> disabilities just as much.  It should be removed.


JR: So is search but it is in ATAG because it is additionally important 
to users with certain disabilities. If we take it out, and a tool 
doesn't do it, we have no way of saying there is an accessibility problem.


> A.2.6 search funtionality is too specific.  There may be other mode to 
> locate things.


JR: There may be others, but we require these.


> A.2.7 Not all functions can be "undoed", especially operations such as 
> file save, delete, and most collaborative funcationalities.  Explicit 
> exception is needed.


JR: We do talk about "reversible actions" - maybe we should define this 
term.


> A.3.1 where the term "observe" is not specific enough.


JR: Follow? Implement?


> A.3.2 does not appear testable.


JR: Maybe this is because it would take an outsider too long to test?


> A.4.1 There are more way to make applications accessible to AT than the 
> like of MSAA.  MSAA and UIA are not capable of meeting all needs from 
> author tool makers.  Implementing only MSAA almost gurantee some 
> functionalities will fail in some cases.  If the rest of the 
> requirements are met and it works with AT, why do you care how we do it 
> from an architecture standpoint?  This is far too prescriptive to be 
> priority 1.  Also, this requirement manipulates market dynamics between 
> platform providers, ISPs, AT vendors.   That is a bad idea.


JR: I'd like to discuss this more. Barry, any thoughts?


> Part B in general--Due to potential legal risk associated with WCAG 
> comformance, I don't think you will find too many commercial authoring 
> tool makers who would that say within the tool itself that doing XYZ 
> with a particular authoring tool would qurantee WCAG compliance 
> content.  This may be the case, even if the tool technically meets part 
> B requirements.  There is too much legal risk to make claims of 
> fulfillment for part B.


JR: Well, technically, they aren't guaranteeing they always produce 
something that meets WCAG 2.0 for example. Instead they are saying they 
meet a Benchmark document (that they can write) that is based on WCAG 
techniques.


> B.2.2 So, everytime we have non-text-content, the author tool as to 
> explain to the user/author how to meet 1.1.1 in WCAG 2.0?  That seems 
> like a lot to ask for an authoring tool to handle something objective 
> like this.


JR: It depends on how smart the tool wants to be about it. The tool can 
handle purely decorative non-text content without asking the user at 
all, some alternatives can be pulled from other sources (B.2.4), and 
special-purpose UI's can be built to make adding ALT easier.


> B.2.4 Why do we need this if we already have B.2.2 (both seem overly 
> demanding)?


JR: Because it is important that tools don't try to make up their own 
alt text - e.g. from file names etc..


Cheers,
Jan

Received on Thursday, 11 January 2007 17:24:03 UTC