RE: AUWG Teleconference on August 8, 2005

Hi Roberto,

Quoting Roberto Scano - IWA/HWG <rscano@iwa-italy.org>:

> GUIDELINE A.?:
> A.?.1 Ensure that browser-accessed functionality conforms to WCAG [Priority
> RP]. 
> 
> Success Criteria: Any component of an authoring tool that is accessed by
> the
> author within a Web browser must conform to WCAG. 
> 
> This means, in a CMS system, that the WYSIWYG editor (= plugin) should be:
> - if script-based, usable also without script (6.3 Ensure that pages are
> usable when scripts, applets, or other programmatic objects are turned off
> or not supported. If this is not possible, provide equivalent information
> on
> an alternative accessible page. [Priority 1] )
> - if an object, directly accessible: eg, using MSAA inside MS Windows, but
> for the other OS?. (8.1 Make programmatic elements such as scripts and
> applets directly accessible or compatible with assistive technologies
> [Priority 1 if functionality is important and not presented elsewhere,
> otherwise Priority 2]) 
> 
> In both cases, there are WCAG priority 1. At now there is a CMS/plugin/tool
> that support this? OR we can put a note like:
> - if a CMS web based application uses technologies referred in WCAG
> Checkpoint 6.3 or 8.1, authoring tools should guarantee that the scope of
> the object is supported also without script and/or object. For eg, in case
> of CMS plugins that have as scope support to edit contents and generate
> valid code the web application should have some checks of server-side for
> retrieve content post by the user (eg: in a simple textarea, where the user
> edit/put HTML code?) and check it for conformance (eg, using Tidy?)

This is a tricky point. Even with its faults, WCAG 1.0 remains the WAI 
recommendation for what constitutes accessible content on the Web. An attempt 
by ATAG to re-prioritize WCAG 1.0 on the basis of what we know in 2005 would be 
a big job (in fact it would be a WCAG 2.0-sized job). Hopefully, WCAG 2.0 will 
come out before ATAG 2.0 and the AUWG won't have to worry about it.


> Another point:
> B.1.3 Ensure that when the tool automatically generates content it conforms
> to WCAG. [Web Content Checkpoints Relative to WCAG] 
> 
> This is a problem, because remember that for WCAG there is a checkpoint:
> 4.1 Clearly identify changes in the natural language of a document's text
> and any text equivalents (e.g., captions). [Priority 1] 
> 
> This cannot do by an authoring tools and also this violates HTML
> specification. Think about, for example, a text equivalent for an image. If
> I've got an image of "Palazzo Ducale" and the page content is in english -
> for respect 4.1 the code should be:
> 
> <img src="palazzoducale.jpg" alt="Image of <span xml:lang="it">Palazzo
> Ducale</span>" />
> 
> But this code is not valid...
> 
> I think that we should check WCAG 1.0 and see what checkpoints can be
> related to ATAG. I can check it, if the group agree.

The example you give does not seem to be specific to auto-generated content 
(which is what B.1.3 is about). Isn't the dichotomy just the same for a user 
typing out content in a text editor? In my opinion, this is WCAG's problem to 
deal with. ATAG should reference their solution.

On the other hand, it may be worth revisiting this checkpoint to make sure that 
(1) it makes sense in the context of adding small segments of Web content and 
(2) that it takes into account that authoring processes may take place in 
steps, during which incomplete content may not be complete and correct.

Cheers,
Jan

-- 
Jan Richards, User Interface Design Specialist 
Adaptive Technology Resource Centre (ATRC), University of Toronto 

  Email: jan.richards@utoronto.ca 
  Web:   http://jan.atrc.utoronto.ca
  Phone: 416-946-7060 
  Fax:   416-971-2896

Received on Sunday, 7 August 2005 14:41:19 UTC