Fw: IBM's ATAG 2.0 comments

I am forwarding this review of the last call document by IBM, from 
Barry, to the list.

Jutta

----- Forwarded by Barry Feigenbaum/Austin/IBM on 01/26/2005 10:28 AM -----
Barry Feigenbaum/Austin/IBM

01/24/2005 01:24 PM
To
w3c-wai-au@w3.org
cc
Subject
IBM's ATAG 2.0 comments




Here are some comments I have collected from IBMers with interest in 
this subject .  I have not filtered the comments all that much (just 
removed personal identifiers and any IBM confidential info).  They 
are grouped by the source (so there may be repeating or conflicting 
comments) .  I have added my thoughts after some of them with BAF 
leads (note I may not always agree with the original comment author's 
position, I need to work more inside IBM to come up with a firm 
consolidated position in these situations - I didn't want to hold 
this input up until I could get that.).

(sorry this comes after last call, it was hard to get this level of 
input to earlier drafts, although I did ask).

Some comments may also already have come in from the source directly.

Overall I think we really need to revisit depending on the ISO 
standard for non-web tools and define our own criteria.  I was queasy 
about this before (since I never actually saw the standard) but now 
that other IBMers have assessed it as is as being problematic, I can 
no longer agree to depending on it solely.

We also need to revisit the disabled JavaScript position.  I think 
our position should be you can use JavaScript and depend on it (ie 
can't be turned off) but the result must be accessible. If not then 
alternate content is required.  Some JS driven GUIs are just to 
complicated and interactive to expect alternate implementations (with 
similar appearance).  Of course, all the functions of the site should 
be available in some form for all users, even if using different UI 
metaphors..


 From an IBM accessibility enablement consultant:

Does Europe require Priority 1, 1 and 2, 1 and 2 and 3?  I might 
change priorities based on how they are viewed.
BAF this is on ISO standard use. The concern is some countries may 
require all criteria to be met.  Big (possibly impossible) burden on 
tool developers.
1) Checkpoint 1.1 I was disappointed that the URL in the ISO - TS - 
16071 does not take you to the document.   Since it is assumed that 
you will use 16071,   for checkpoint 1.1 I think a direct link is 
needed.  What priority is this checkpoint?
BAF can we link to this document. I don't think so (cost issues).  As 
I said before, I think we need a good condensation of this standard 
in our document to prevent the hard dependency on getting the ISO 
document.  maybe we need to rethink depending on another body for 
these criteria.
2) Checkpoint  1.2  I can only assume that ISO - TS - 16071 does not 
address element and object properties which is the reason they are 
called out here. What priority is this checkpoint?
3) Checkpoint 1.4   Why is this important and unique in reference to 
navigation and editing?
4) Checkpoint 2.2  Since this Specification is so closely coupled 
with WCAG is it possible to find away to have Version 3.0 of each 
come out at the same time?
5) Checkpoint 2.3 What priority is this checkpoint?
6) Checkpoint 2.4 - I would include that all samples/examples are 
accessible and conform to WCAG 2.0, What priority is this checkpoint?

 From a WCAG member:

Guideline 1.1 -
  I have concerns that "At least one 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Full-Featured>full-featured 
Web-based 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Authoring-Tool-Interface>authoring 
interface must always 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#priority-Relative-To-WCAG-Interface>conform 
to WCAG. "   Since WCAG 2.0 is not released yet, a current web tool 
cannot conform to WCAG 2.0 and thus MUST conform to WCAG 1.0.  It 
would be practically  impossible for a full featured web based 
authoring tool to conform to WCAG 1.0 because of the following WCAG 
priority 1 checkpoint:  "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] "   I realize that WCAG 
2.0 isn't complete and ATAG must rely on WCAG 1.0 but I think some 
concessions should have been made since JavaScript is so much better 
supported since WCAG 1.0 was released.  I think it is good that ATAG 
and WCAG and UUAG are being related but the versioning skew between 
the documents may cause issues.
BAF I know we dealt with version references issues before, but this 
is a particularly important one (ie scripted page 
accommodation/alternatives) that we need to addresses the situation 
in our own criteria, not delegate to another standard.


Guideline 1.3 Success criteria 2: All 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Editing-View>editing 
views must always include an option to keep the display settings of 
the 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Authoring-Tool-Interface>authoring 
interface from affecting the 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Web-Content>Web 
content being edited.
Implementation techniques 1.3.2 and 1.3.3 conflict - you can't have 
both. If the web tool is honoring system display settings, the tool 
itself and any preview of created content will display in the system 
settings.  
Technique 1.3.2: Respect system display settings.
Technique 1.3.3: For tools with editing views, provide the author 
with the ability to change the fonts, colors, sizing (zoom), etc. 
within the editing view, independently of the ability to control the 
markup that is actually produced. [STRONGLY SUGGESTED]
BAF we need to clarify this so that we make the strong separation 
between the use/definition of settings for previewing authored web 
content and the use/definition of settings used by the tool outside 
any preview windows.  The settings may be totally different in these 
two contexts. Also we need to make sure that the reader understands 
that we are saying that the tool's settings should not dictated the 
settings used in any authored web content (ex settings for any 
generated CSS info) or preview view of that content, that is they are 
independent (but the may share defaults).

Guideline 1.4 Success Criteria 2

I have concerns that this  technique may not be achievable in all web 
interfaces and widgets:

Technique 1.4.5: Allows the author to move among, select, copy, cut, 
or paste elements of the document.

On the web, the following techniques seem to be more of a function of 
user agents
Technique 1.4.7: In a hypertext document, allow the author to 
navigate among interactive elements of content (e.g. links, form 
elements).
Technique 1.4.8: Allow editing view navigation of content by any 
accesskeys defined in that content.

BAF we may need to distinguish support in web vs. non-web tools to 
address these concerns.



Guideline 2.1 Support formats that enable the creation of Web content 
that conforms to 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#Relationship-To-WCAG>WCAG. 
[Priority 1]
I have the same concerns here as for Guideline 1.1 - issues with WCAG 
1.0 and JavaScript.  We should allow tools to generate JavaScript as 
long as the generated JavaScript is accessible and not require sites 
to run with JavaScript turned off.

Do Success Criteria 1 & 2  mean that you can't use a format for 
content if there is no WCAG techniques document for it?  I certainly 
hope not - that could stifle new technologies!!!  The checkpoint 
techniques make it a bit clearer, but I find the Success Criteria, as 
written, confusing.
BAF my understanding is - if no WCAG techniques doc then the format 
can't be used and conform to ATAG (unless alternative conforming 
content is provided).  If correct, we are putting a strong dependency 
on the creation of WCAG techniques docs by the format creators (or 
others).  We need to make sure this dependency is well and widely 
know so it will be meet.

Guideline 2.3
  includes a Note that WCAG includes a validation requirement. While 
this is true,  WCAG 2.0 allows for non-valid content if it improves 
the accessibility.
BAF we should allow this exception too (not sure when invalid content 
turns out to be more accessible, but if that truly is the case...)

Guideline 2.4 - same conformance to WCAG concerns.

Guideline 3.1
I was happy to see this definition of prompt - I hate intrusive interfaces!
Clarification of Term "Prompt":The term prompt in this checkpoint 
should not be interpreted as necessarily implying intrusive prompts, 
such as pop-up dialog boxes. Instead, ATAG 2.0 uses prompt in a wider 
sense, to mean any tool initiated process of eliciting author input 
(see 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Prompt>definition 
of prompting for more information).

Guideline 3.2
I disagree with success criteria 2:  The authoring tool must always 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Inform>inform the 
author of any failed check results prior to 
<http://www.w3.org/TR/2004/WD-ATAG20-20041122/#def-Comp-Authoring>completion 
of authoring.  If the developer performs a manual check (as allowed 
by success criteria 1), I don't think the developer needs a reminder 
of failed results when exiting.   I can live with this guideline but, 
to me, it verges on intrusive.
BAF sort of agree, especially if the tool is not aware of the 
failures detected by the human in the manual check.

Guideline 3.3 - back to that JavaScript issue again.....
It would be very difficult for an authoring tool to suggest 
alternatives for JavaScript which work with JavaScript turned off. In 
some cases to work without JavaScript might require additional pages 
to be created.
BAF I agree that this means extra effort.  IMHO extra pages is the 
most common way authors would compensate for disabled JavaScript and 
that the tool should go out of its way to make the user realize these 
extra pages are needed to compensate or that a redesign is needed..  

I will be interested in seeing the "proof of concept" web authoring 
tool that meets all of the Priority 1 checkpoints - it isn't going to 
be easy!
BAF indeed it will be.  I doubt one exists, we either need to 1) 
commission the creation of one or 2) find partial solutions across 
many tools.  I think, while a lot of effort, 1 is the most likely to 
succeed. It will also be the "best" example to learn from..The ATAG 
techniques doc could be a "spec" for this tool (the tool does not 
need to be all that functional (ie really generate web content) or 
self consistent, mostly just show good UI options)

 From a Protocols member

ATAG 2.0 is important, especially for the EU and IBM is preparing to 
support these guidelines in some of our products now, however these 
new issues are a problem. Hopefully they can get resolved quickly.

This is my review of ATAG 2.0: http://www.w3.org/TR/2004/WD-ATAG20-20041122/

- Section 1.2

Modify: Examples: timelines, waveforms, vector-based graphic editors, etc.
To include: objects which represent web implementations for graphical 
widgets (menus, etc.).

Under indirect authoring functions include model-based authoring tools

- Guideline 1.1, 1.2

This section says conform to WCAG. For P1 this definition, 
http://www.w3.org/TR/2004/WD-ATAG20-20041122/#priority-Relative-To-WCAG-Interface, 
includes the following in WCAG 1.0:

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]

This is wrong and should be struck or should be written such that P1 
can be satisfied for WCAG 1.0 or WCAG 2.0 P1. Any reference to WCAG 
1.0 should be removed or modified. This WCAG 1.0 checkpoint is 
obsolete. I am concerned that this impacts both JavaScript generated 
content as well as XForms where, in fact, programmatic objects are 
bound to the data model and follow an active MVC architecture. This 
would appear that a mode should be available to turn active content 
off in the user agent and still work or that someone would need to 
provide an alternative page equivalent for this type of content 
although it is not how this would work in the case of forms which are 
active.
BAF  Alternative content should be a requirement in the case where 
the "active" content cannot be made accessible (less and less of a 
problem over time I expect) and is core to the use of the web site 
else the user is denied some function of the web site.  We probably 
need to disconnect the criteria from WCAG so we lose the version 
dependency.  Also we cannot force site to run without JavaScript 
entirely as too many sites depend on it now. We many want to lower 
the priority of this as it is so costly to meet.  Maybe we need to 
add the "core to use" condition (ie vs implying just any JavaScript 
needs an alternative)


- Guideline 1.3

The technique 1.3.1 for implementing this calls for respecting system 
font and color information. How does this meet this checkpoint in and 
by itself?

- Guideline 1.4

This requires the author to perform structure-based edits. The 
document structure being edited should be without error correction 
performed. Assistive technology vendors often have to deal with bad 
content as the DOM structure they are processing does not match that 
which is rendered. So, if the authoring tool operates off of 
corrected content the results may not meet the needs of the impaired 
user while being used by an assistive technology. This should not be 
limited to only target device independence.

The second issue is that the author must be able to enumerate the 
available actions which can be taken at a given object and 
selectively activate them. For content which provides text 
equivalents for the corresponding action such as the new access 
feature in XHTML 2.0 this information should be provided to the 
author. An action may cause an action to occur which moves focus.

- Guideline 1.5

In XHTML 2.0 we are introducing the role attribute and other 
important meta data which is important for authoring tools. This 
includes search for text equivalents for non-text objects. Does this 
include things like role meta data which includes additional 
semantics vs. simply a text alternative? This is not clear. It should 
be clarified either in the document or its techniques.
BAF: we need to look more closely at XHTML 2.0 to see if it has 
features we need to explicitly account for in these guidelines.

How do the navigation techniques here map to UAAG 1.0? Where is the 
reference to UAAG 1.0?

- Guideline 2.1

This would indicate we (HTML working group) need to publish a WCAG 
2.0 conformance techniques document for XHTML 2. This means any 
existing content recommendation which does not have a WCAG 
conformance techniques document does not comply with ATAG 2.0.
BAF: As we did discuss, there is concern about this in that all 
popular content types don't have techniques documents.  Is there any 
other way we can qualify content types as accessible so they can be 
used and still meet ATAG?

- Guideline 2.2

In this success criteria, I don't see why the ATAG group would allow 
the author to be able to knowingly remove accessibility information 
(iii) and still be compliant with this checkpoint

- Guideline 2.4
expand (e.g. to include objects which represent web implementations 
for graphical widgets (menus, etc.).

- Guideline 3.5

This only addresses things like alternative text such that you could 
render the alternative text alone and that would be adequate for the 
content user. This guideline should be extended or a new guideline 
should be added to include ANY accessibility related meta data. This 
will include Role meta data in xhtml 2, XForms labels, XML event 
descriptions, upcoming state attributes from the WAI PF working 
group. The role is not considered an "alternative equivalent" as 
stated. Other information such as state data are required for things 
like check boxes. This has a WCAG 1.0 flavor and does not include new 
content being created which provides for improved semantics.
BAF again, I think we need to look into other newer WAI specs to 
understand the new types of "content" that may exist.

- Conformance section 2.1.2

Again, for WCAG compliance priority levels it should be either WCAG 
2.0 priorities or WCAG 1.0 or WCAG 2.0 for a given priority level 
(not both).

The group is using ISO-TS-16071 to define the accessibility of the 
non-web application . How does this map to 508? Are you introducing 
additional requirements on companies. This may create a barrier to 
adoption in the United States and other geos. Somebody from ATAG 
needs to provide a matrix which describes the differences and 
equivalents for review and if adopted, the matrix should be published.


from a WCAG member, issues with ISO 171 standard:

BAF: if we continue to use this standard as a base, we need to 
clarify the application of priorities.  We also need to contrast it 
to other common standards that may apply (especially US section 508) 
as many tool vendors desire to conform to these standards as well. 
 Certainly we don't want to have conflicting rules (one standard 
requires something another explicitly disallows). Again this is a 
reason to revisit the delegation to ISO.  Note that this is an early 
assessment and may be revised or extended (i.e., more issues found).

ISO 9241 Part 171 has two priority levels - Required and Recommended. 
It also specifies, for each requirement, whether it is an application 
only requirement, an OS only requirement, or both an application and 
OS requirement. IBM is concerned mostly with the application 
requirements but we also looked at the OS only requirements for their 
impact to IBM operating systems.


Application only:

8.15 Enable user control of time-sensitive information: 508 
1194.21(h) requires that information presented in an animation also 
be available in a non-animated form. This ISO item requires that 
software provide a way to stop or pause moving, blinking, scrolling 
or auto-updating information.
10.2.1.4 Enable individualization of user interface elements: As 
worded, apps would have to provide a mechanism enabling users to 
individualize the interface look and feel including the modification 
or removal of command buttons.
12.1 through 12.7: These are requirements on multi-modal interfaces. 
There is not enough information provided to understand the 
requirements. we cannot assess the impact of these requirements until 
we have more information.

Both application and OS:

8.1.2 Use the OS accessibility services: This would disallow any 
accessible Java applications since the Java AAPI is not an OS 
accessibility service.
8.2.1 Enable user input/output choice: This is the fundamental 
accessibility principle. All of the requirements in 508, CI 162, and 
even this proposed ISO standard are specific techniques for providing 
this function. This is too broad to be an additional conformance 
requirement and it should be removed.
8.3 Enable full use via keyboard: 508 essentially excludes drawing 
applications. ISO does not.
8.11 Enable persistent activation: This was the lowest priority in 
the previous draft but has been raised to the highest priority in 
this draft. This would require tear-off menus and "settings" dialogs 
that remain open (as in Lotus apps vs. MS Office apps)
10.1.3.2 Provide keyboard input from all standard input mechanisms: 
If OS provides, app doesn't have to. But if OS doesn't provide an 
onscreen keyboard to allow mouse input of keystrokes, for example, 
app would have to provide it. This should be changed to an OS only 
requirement.
10.1.3.5 Enable the re-assignment of (mouse) button functions, 
10.1.3.8 Provide individualization of delay of pointer-button-press 
acceptance & 10.1.3.12 Provide individualization of pointer movement 
acceleration adjustment: The way these are worded, apps would have to 
provide these mouse customization functions if the OS doesn't. Should 
either be OS only requirement or explanation reworded to clarify that 
apps only have to support if OS provides the service.
10.2.1.3 Enable individualization of cursor and pointer: Should be OS 
only requirement. Apps should only be required to support if OS 
provides the service.
11.1.4.1 Enable font individualization and legibility: 1194.21(g) 
support user display settings. If OS doesn't support, no requirement 
in 508 for app to provide. 1194.31(b) requires a mode of operation 
that does not require visual acuity greater than 20/70 or support for 
assistive technology used by people with visual impairments. ISO 
9241-171 requires apps to provide this function even if the OS 
doesn't.
11.1.5.6 Provide contrast between foreground and background: Requires 
software to choose foreground and background colours (hue and 
luminance) that provide contrast regardless of color perception 
abilities.
11.1.6.7 Synchronize speech output: Requires speech to appear 
immediately after the event that triggered it. This is a bad 
requirement. The events don't originate the speech output. The events 
are passed to the AT. The AT then decides what to do. It may or may 
not invoke speech output via the OS speech APIs. But it cannot be a 
requirement on the OS or the application because it's completely out 
of their control.
11.2.2.1 Provide understandable documentation: This is not measurable.

OS only:

8.1.1 Enable communication between software and assistive technology: 
Impacts i-series and z-series unless we can satisfy this requirement 
through emulation on an OS that supports this requirement. x-series 
(AIX) will not support until Gnome API is golden.
8.4 Accept the installation of keyboard and/or mouse emulators: 
Impacts x-, i-, and z-series.
8.17 Provide accessible system start-up and restart: Impacts x-, i-, 
and z-series
8.18 Enable software-controlled media extraction: Impacts x-, i-, and z-series
10.1.1.5 Provide individualization of delay before key acceptance 
(Slow Keys): Impacts x-, i-, and z-series
10.1.3.18 Provide pointer control of keyboard functions: This is a 
duplicate of 10.1.3.2 and should be removed.
10.1.4.1 Be speech recognition friendly: Impacts x-, i-, and 
z-series. Requires OS to provide speech reco APIs.
11.1.6.6 Provide speech output services: Impacts x-, i-, and 
z-series. Requires OS to provide TTS APIs. Mentions Java speech API 
as an example which is interesting since Java is not part of the OS.


Application only:

11.1.1.1 Start, stop, pause and replay media : Only affects "player" software
11.1.1.2 Allow user to control presentation of multiple media steams: 
requires user to be able to turn off audio and view captions only. 
Supporting the system setting to mute the sound should be sufficient 
to meet this requirement but this is not explicitly stated.
11.1.6.8 Use tone pattern rather than tone value to convey 
information: Only applicable to software that generates tones. 
Requirement is to use temporal or frequency-based tone patterns 
rather than using a single absolute pitch or volume.
11.1.6.9.1 Display any captions provided: "Player SW" only. Must have 
ability to display captions.
11.1.6.9.3 Support system settings for captioning: Example would 
require an application to display captions if ShowSounds is enabled.

Both application and OS:

9.6 Allow assistive technology to access resources: Only required if 
the OS provides the service. Must allow the AT to get the resources 
it needs to run. We used to have this in the Java checklist.
9.7 Present user notification using consistent presentation 
techniques: Example is displaying status messages in a consistent 
status area of the window and error messages in a message box. This 
requirement is not addressed by 508 but we expect that this is not an 
issue for most IBM software.
10.1.1.3 Enable generation of keyboard input: Says you have to be 
able to generate keyboard input from other input devices or SW. We 
think this is the job of the OS standard input APIs and apps are 
required to use standard input per 9.1.
11.2.1.1 Allow task-relevant warning or error information to persist: 
CI 162 allows this as one method of meeting the timed response 
checkpoint.

OS only:

10.1.1.4 Enable sequential entry of multiple keystrokes (Sticky 
Keys): 508 1194.21(b) requires only that software not interfere with 
accessibility features of the OS. There is no requirement for the OS 
to provide them. This is an issue for IBM operating systems (i-series 
and z-series) but we don't think they use multiple keystroke entry. 
ACTION: confirm this.
10.1.1.10 Provide parallel keyboard control of pointer functions 
(Mouse Keys): 1194.21(b) requires only that software not interfere 
with accessibility features of the OS. There is no requirement for 
the OS to provide them. This is an issue for IBM operating systems 
(i-series and z-series) but we don't think they use mouse input at 
all. ACTION: confirm this.
10.1.3.14 Finding mouse pointer: Could impact i-series and z-series 
but they don't support mouse input at all.
11.1.2.4 Provide access to information displayed in "virtual" screen 
regions (OS only requirement): Requires scrollable dialog boxes so 
that if the text size is enlarged to the point where the dialog box 
won't fit on the screen, the user can scroll to see the virtual 
screen areas. Impacts i-series, x-series, and z-series.
11.1.3.3 Enable "always on top" windows (OS only requirement): 
Impacts x-series, i-series, and z-series.

Not specified:

10.1.3.3 Direct external control of mouse position: There is no 
specification whether this requirement is for OS only, application 
only, or both. The explanation talks about the mouse driver so we 
suspect this will be an OS only requirement. If so, it might impact 
i-series and z-series but they don't support mouse input at all.
10.1.3.15 Enable pointer individualization: There is no specification 
whether this is for OS only, application only, or both. This should 
either be OS only or apps should only be required to support it if 
the OS provides the service.


Application only:

9.1 Use system standard input/output: 508 addresses this only for 
output of text in 1194.21(f). Standard keyboard input is implied by 
1194.21(a) but not specifically stated. Only a problem for apps that 
do not use standard mouse and keyboard inputs.
11.1.1.3 Update equivalent alternatives for dynamic content when the 
dynamic content changes (application only requirement): Requires 
captions and audio descriptions to be kept current with content. Not 
specifically addressed by Section 508 but if the equivalent 
alternatives don't match the dynamic content, they are not equivalent 
so we believe this is implied.

Both application and OS:

9.3 Make event notification available to assistive technologies & 9.5 
Allow assistive technology to change the focus and selection 
attributes: This is only required to be supported by apps if the OS 
provides the service. 508 doesn't have this specific requirement 
however 1194.21(l) requires forms to be accessible. We don't believe 
forms could be made accessible without meeting these requirements. As 
long as apps use the system event APIs, this should not be an issue.
10.1.1.16 Separate keyboard navigation and activation: Not specified 
by 508 but 1194.21(a) Keyboard operation is not really possible 
unless you have this. Should add to required techniques in SW 
checklist.
Barry A. Feigenbaum, Ph. D.
Worldwide Accessibility Center - IBM Research
www.ibm.com/able,
w3.austin.ibm.com/~snsinfo
voice 512-838-4763/tl678-4763
fax 512-838-9367/0330
cell 512-799-9182
feigenba@us.ibm.com
Mailstop 904/5F-021
11400 Burnet Rd., Austin TX 78758

W3C AUWG Representative
IBM Club Representative
IEB Member

Sun Certified Java Programmer, Developer & Architect
IBM Certified XML Developer; OOAD w/UML

This message sent with 100% recycled electrons