ATAG2 SCs lacking implementation examples

On the call Jutta brought up the issue of the difficulty of finding 
implementations for SCs that address accessibility issues that may 
currently be fairly rare. The concern is that simply avoiding the 
obstacles in the first place (which is a good thing) might not count as 
an implementation. At the same time, we don't want to go too far the 
other way and potentially ignore implementations that tackle the issue 
effectively.

I thought I would have a look to see how big a problem this is. This is 
what I found with some discussion ("JR:"):

A.3.2.3 Moving Targets: If a user interface component is moving (e.g., 
animated vector graphic), then authors can pause the movement.

JR: This is the SC that caused our concern. We haven't found a tool that 
actually has moving UI components (lots of tools can put things in 
motion (e.g., timeline indicator), but typically the things moving are 
not targets of UI interaction (e.g., clickable areas). I suggest a 
re-wording:
"A.3.2.3 Static Pointer Targets: User interface components that accept 
pointer input are either stationary or authors can pause the movement."
(Since the Last Call is stalled at the moment due to processes beyond 
our control, maybe we can get this approved before publishing.)


A.3.6.4 Options Assistance: The authoring tool includes a mechanism to 
help authors configure any options related to Part A of this document.

JR: This one just caught my eye. The only implementation example is a 
special wizard, but really if there is an accessibility section to the 
preferences with proper documentation of the available setting choices, 
I think this is enough.


B.1.2.2 End Product Cannot Preserve Accessibility Information: If the 
web content technology of the output of a web content transformation 
cannot preserve recognized accessibility information (WCAG 2.0 Level A) 
(e.g., saving a structured graphic to a raster image format), then at 
least one of the following are true:
(a) Option to Save: Authors have the option to save the accessibility 
information in another way (e.g., as a "comment", as a backup copy of 
the input); or
(b) Warning: Authors are warned that this will result in web content 
accessibility problems in the output.

JR: As a practical matter, if the output format is unable to hold 
accessibility information, it's probably unlikely that a tool would try 
to conform with respect to the production of that output format. 
However, there are lots of conversion possibilities where accessibility 
could be a problem, so I think this is worth keeping.


B.2.4.2 Automated suggestions: During the authoring session, the 
authoring tool can automatically suggest alternative content for 
non-text content only under the following conditions:
(a) Author Control: Authors have the opportunity to accept, modify, or 
reject the suggested alternative content prior to insertion; and
(b) Relevant Sources: The suggested alternative content is only derived 
from sources designed to fulfill the same purpose (e.g., suggesting the 
value of an image's "description" metadata field as a long description).

JR: I think we actually want to encourage suggestions of accessibility 
information from relevant sources (see "B.2.4.4 Save for Reuse: Authors 
have the option of having any recognized plain text alternative content 
that they enter (e.g., short text labels, long descriptions) stored for 
future reuse.") so I think we should keep it as is.

Cheers,
Jan

-- 
(Mr) Jan Richards, M.Sc.
jan.richards@utoronto.ca | 416-946-7060

Adaptive Technology Resource Centre (ATRC)
Faculty of Information | University of Toronto

Received on Wednesday, 19 May 2010 16:58:56 UTC