Re: Some minor adjustments of criteria

My replies in-line:

Tim Boland wrote:
> 
> My replies following..
> 
> At 10:46 AM 11/10/2004 -0500, you wrote:
> 
>> Thanks for the input Barry. Everyone else, please keep it coming.
>>
>> I've added these issues to the draft at:
>> http://jan.rcat.utoronto.ca/public/auwg/guidelines.html
>>
>> Barry Feigenbaum wrote:
>>
>>> Hate to be a thorn in the side but I still think the success criteria 
>>> for guidelines 1.5 should start "At least one" (vs "All").  As it 
>>> stands now, I think we over constrain the developer.   The tool does 
>>> not need to provide the feature everywhere; just in enough places to 
>>> allow a user to successfully author content.
>>
>>
>> JR: This makes sense to me.
> 
> My concerns with the proposed change: (1) there is no motivation (or 
> credit) to shoot towards "all" if "at least one" would suffice, (2) the 
> change would introduce an extra dimension of variability in authoring 
> tools (one authoring tool would do it one way, another authoring tool 
> another way - I feel that such variability may tend to reduce 
> consistency of authoring tool behavior across different authoring tools 
> ("interoperability" issue?) , and (3) objective testability of "in 
> enough places" and "successfully author content" may be in question.

JR: The reason I support the change is because certain types of search 
make sense in some views but not others. For example, a text search of 
markup (ex. searching for the string "<ul><li") makes sense in a 
code-based view but not in a rendered view, because how would you show 
the author the detected instance.

I'm not sure how this negatively impacts "objective measurement". Most 
tools will probably allow searching of information within views that is 
meaningful in the context of that view.

>>> Also criteria for 1.4 should not imply only select, cut, copy and 
>>> paste need to be supported.  Any service (such as print, email, etc) 
>>> that is provided for the element should be similarly accessible. We 
>>> might want to edit the criteria from "In any element hierarchy..." to 
>>> "In any presentation of any element hierarchy..."   The underling 
>>> model should not be required to support these behaviors, just viewers 
>>> and editors.
>>
>> JR: Remember that the checkpoint says "perform structure-based edits". 
>> If we mean all services, then we would need to change the checkpoint. 
>> Personally, I'm ok with the way it is since I think its edits that 
>> really need to be structure based. Services like print and email can 
>> be if the developer chooses (and if they are they must conform to 1.1).
> 
> I tend to agree with Barry on this one, if the accessible provision of 
> these services can be objectively measured.

JR: Remember, the main thrust of this checkpoint is not that "select, 
copy, cut and paste" be accessible (checkpoint 1.1 takes care of that). 
Instead the main thrust is that "select, copy, cut and paste" be 
available in a structure-based way (because it expedites editing for 
people who are limited in their keystroking). Other structure-based 
services are possible, but ATAG 2.0 is not requiring them.

As it stands, I think "objective measurement" is possible.

>>> For criteria for 2.4 I think we need to broaden the last phrase ("... 
>>> must always conform to WCAG") to something like: "... literally (as 
>>> stored) must conform to WCAG or conform to WCAG as generated 
>>> (inserted/added) in the Web content".  Some content may not conform 
>>> as stored/distributed, but will be massaged as inserted by the tool. 
>>> Only the resulting content need be WCAG conformant.
>>
>> JR: This makes sense to me.
> 
> My concern is that the proposed change weakens the success criterion, 
> introduces variability across different authoring tools as mentioned 
> previously, and makes testing more difficult (when is content 
> "resulting" as opposed to "stored/distributed", and how can this be 
> objectively measured?).

JR: Imagine a clip-art management system that works as follows: it 
stores jpgs in a folder along with a text document that includes an 
index of the images as well as accessibility information (text labels 
and long descriptions) for each image. When the author chooses to 
"Insert Clip-Art" they choose from amongst the images and the authoring 
tool automatically retrieves the accessibility information and adds it 
to the image. I think this example should pass even though the storage 
mechanism does not conform to WCAG, because when the system is used it 
does not introduce accessibility problems.

Perhaps we should add a concept like "immediately accessible" (not the 
best wording) that means that content is free from accessibility errors 
if the author immediately takes the shortest path to completion (e.g. 
"saves" and "exits" OR continues with a wizard until the first 
possibility to "finish") and the Web content, so produced, lacks 
accessibility problems.

If we had such a concept, we could say that when pre-authored content is 
opened or inserted it must be _immediately accessible_. (I'm using Tim's 
"_" rather than my "*" to show the linked term)

Received on Wednesday, 10 November 2004 19:39:52 UTC