Re: AUWG Action: to Track down our text re: passing through content authored on other tools

Looking at this some more...I see we have notes on applicability in the 
"Definition of authoring tool" section as well as at the top of Parts A 
and B.

I think we should:

(1) reserve the "Definition of authoring tool" section for notes about 
authoring tools in general (e.g., the list of examples and the note on 
real-time tools), which means moving the other note ("Any guidelines 
that require authors to modify content in some way always assumes that 
the person has author permission.") down to Part B (with the handle 
"Author Permission").


(2) Re-work the points in Part B, so that they now read (especially see #5):

1. Authoring Systems: As per the definition of authoring tool, several 
software tools can be used in conjunction to meet the requirements of 
Part B (e.g. an authoring tool could make use of a third-party software 
accessibility checking and repair application).

2. Author Permission: Any success criteria in Part B that may require 
modification of content only apply when an *author* has *author permission*.

3. Author Availability: Any success criteria in Part B that refer to 
authors only apply during *authoring sessions*.

4. Responsibility after the *End of Authoring Sessions*: Authoring tools 
are not responsible for accessibility problems that result from carrying 
out instructions made by authors during a previous authoring session 
(e.g., displaying third-party content specified by an author). Authoring 
tools are responsible for any changes that are automatically-generated 
(e.g., when a CMS *developer* makes site-wide changes).

5. Outputted vs. Referenced Web Content: The success criteria in Part B 
apply to only Web content technologies that the authoring tool outputs 
and which have been listed in the conformance profile. The success 
criteria in Part B do not apply to Web content technologies that an 
authoring tool is only able to reference (e.g., by URI), but not output. 
For example, a particular HTML authoring tool might insert an image by 
outputting HTML content (e.g., an img element) and referencing the image 
content (e.g., a URI to a PNG image). By Part B, that authoring tool 
must provide supports for HTML *accessible authoring practices* (e.g., 
providing alt text for images), but not for PNG accessible authoring 
practices (e.g., ensuring sufficient contrast).

----

BTW: I think we should ensure that widget sets (e.g. DOJO) can be 
included as technologies in conformance claims separate from their 
constituent technologies (e.g., HTML, Javascript) because I can imagine 
an editor that can support an author in creating an accessible DOJO form 
but that can't support in the production of accessible Javascript in 
general.

Cheers,
Jan








Cheers,
Jan


Jan Richards wrote:
> Hi all,
> 
> Here's the ATAG 2.0 text I was looking for:
> 
> "Existing Technologies: The success criteria in Part B only apply to 
> support for accessible authoring practices that are relevant to 
> technologies that the authoring tool already has the ability to create 
> or edit. For example, a markup authoring tool that adds images by simply 
> linking to their URIs would be required to support the production of 
> alternative text for images in the markup, but it would not be required 
> to add image editing functionality to ensure sufficient contrast in case 
> any images are of text."
> 
> I think this could be made more clear (especially the handle). More 
> thoughts to follow later in the week.
> 
> 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, 28 April 2009 20:34:01 UTC