Re: Proposal for ATAG Checkpoint 4.X (JR Action Item)

Hi Tim,

I made your changes. Does "presented" work? I suppose it will need to be
defined. Here is how it reads:

If the user begins a Web content editing session, performs edits that
introduce accessibility problems, saves and then exits an editing
session, then the tool must have, at some point during the editing
session, PRESENTED the user with relevant prompting,
checking, repair or documentation features.

Cheers,
Jan



Tim Boland wrote:
> 
> For success criteria, "at some point -during the editing session-" (add
> last part)?  Also is there any way to quantify "reasonably obvious
> way"?   Term seems somewhat subjective.
> 
> Great job!
> 
> Tim Boland NIST
> 
> Also, At 10:17 AM 11/7/2003 -0500, you wrote:
> 
> >Here's what I've come up with for the 4.X stuff:
> >
> >1. I've changed the checkpoint to make it more similar to others in GL4.
> >2. I've added a new sentence to the rationale from Karen's email (marked
> >by **)
> >3. I've added a potential success criteria.
> >
> >==============================================================================================
> >
> >4.X Ensure that *accessibility prompting, checking, repair functions and
> >documentation* are integrated into the overall workflow when an author
> >develops Web Content. (Priority 2)
> >
> >RATIONALE:
> >
> >Accessible design as an afterthought or separate process is much more
> >onerous and therefore costly than when accessibility is considered from
> >the start. *Experienced authors develop workflows, familiar and
> >consistently successful routines, with their authoring tools.* If the
> >authoring tool supports a workflow in which the author considers
> >accessibility before and/or during the authoring process it is more
> >likely that accessible authoring practices will become a common
> >practice.
> >
> >SUCCESS CRITERIA
> >
> >* If the user begins a Web content editing session, performs edits that
> >introduce accessibility problems, saves and then exits an editing
> >session, the tool must have, at some point, intervened in a reasonably
> >obvious way with one or more accessibility prompting, checking, repair
> >or documentation features relevant to those accessibility problem.
> >
> >====================================================================================================
> >
> >I realize that the success criteria is a bit spartan. However, the range
> >of conceivable workflows for all the different types of tools and
> >operations that might be performed with them is very large. Moreover, we
> >are quite clear about the need for user configurability, which
> >complicates the situation.
> >
> >Thoughts on any of this?
> >
> >Cheers,
> >Jan
> >

Received on Wednesday, 12 November 2003 16:26:20 UTC