Re: Classification of AT in ATAG2

Charles McCathieNevile wrote:

> GUIDELINE 1: Ensure that the tool itself is accessible
> 1.1 Ensure that the authoring interface follows applicable software 
> accessibility guidelines. ([Priority 1] for required elements of the 
> software accessibility guidelines; [Priority 3] for recommended elements 
> of the software accessibility guidelines.)
> 
> This should be straightforward - the applicable guidelines in this 
> case are WCAG.

This is rather muddled and ill defined.  Web Accessibility Guidelines 
applies to web applications, whereas Software Accessibility Guidelines 
apply to applications software.  You can't bundle the two together 
because they each are governed by different functional environments.

http://trace.wisc.edu/world/computer_access/software/
http://www.tracecenter.org/world/computer_access/
http://www-3.ibm.com/able/guidelines/software/accesssoftware.html


> 1.2 Ensure that the authoring interface enables accessible editing of 
> element and object properties. [Priority 1]
> 
> Hmm. This isn't one hundred percent clear - does accessible mean that 
> you can substitute easy-to-uunderstand images for bizarre bits of code? 
> Anyway, at a trivial level accessible only to people who don't have 
> certain disabilities, Wiki software allows structure to be edited 
> relatively easily in a textarea.

You bet this isn't clear.  Here you have a term that links "element and 
object properties" in the one sentence.  So that to me means all the 
standard markup elements, and those that are not, which are classified 
as objects, as in "Objects, Images & Applets", yet all the links in this 
document seem to be referring to element attributes.

HTML Top-level Elements

     * Head
     * Body
           o Text
           o Lists
           o Tables
           o Links
           o Objects, Images & Applets
           o Style Sheets
           o Frames
           o Forms
           o Scripts

Whatever the case, there needs to be very clear distinction made here, 
because the assumption is that the AT, whatever it is, Application 
software, web form or text editor should be able to edit the object 
properties, and the Rationale and the Success Criteria point to 
graphical type editors that can edit Objects, Images and Applets.


> 1.3 Allow the display preferences of the authoring interface to be 
> changed without affecting the document markup. [Priority 1]
> 
>   This is a matter of being able to apply a stylesheet for the authoring 
> interface page. The possibilities that browsers offer for textarea 
> elements themselves at the moment are surprisingly limited, for no 
> particularly obvious reason. This is the sort of thing that Xforms (a 
> W3C Recommendation with a number of implementations) does a lot better 
> than old-fashioned forms, so we can expect a steady improvement in this 
> area.

If that is the case there are very few who can meet the Success Criteria 
as stated.  I'd like to see any examples of web based authoring 
environments that meet this criteria.


> 1.4 Ensure that the authoring interface enables the author to navigate 
> the structure and perform structure-based edits. [Priority 2]
> 
>   One way to do this is to provide an interface directly to the 
> structure - something like Amaya's structure view - which allows for 
> selecting parts of the structure and performing assorted operations on 
> them. There are plenty of tools that layout an outline view - 

Amaya is a user agent and software application, as such it has far more 
power to manipulate content, web forms don't have this range of capacity.

> doing this 
> in a form, where you can select things like changing the nesting level 
> of lists or list items, or the level of headings, is not very hard. 

Please show me an example.

> Selecting a section and moving it to another part is slightly more 
> complex - you need to implement a few functions at once - but hardly 
> rocket science. A copy/paste buffer isn't exactly a new idea, for 
> example - even one that holds multiple items.

Please show me an example.

> 1.5 Ensure the authoring interface allows the author to search within 
> the editing views. [Priority 2]
> 
>   Web pages do this pretty much automatically. Being able to look for 
> particular structures would be a neat improvement that this kind of tool 
> could offer.

But try and do this within a web form.  Please show me an example.

Also, what do you do in the case of web forms that need to comply with 
WCAG1 6.3.  Take for instance phpBB, like many web based authoring 
interfaces, used at http://www.accessifyforum.com/.  If Javascript is 
turned off you loose all power of the toolbar and the user interface to 
markup the content for the backend to process.

***
I leave out the other guidelines for the present, also because it is the 
1.x guidelines applied to ATs across the board that concerns me.

Also, I take to understand everything above referring to the capacity of 
web forms as AT can apply within any user agent, including Lynx, so as a 
  web developer, is ATAG2 saying that I should be able to build a fully 
compliant AT using web based forms usable within any user agent?

Geoff

Received on Saturday, 13 December 2003 18:28:11 UTC