IBM Feedback: ATAG 2.0 W3C Working Draft 08 July 2010

Hello,

IBM feedback on the ATAG 2.0 W3C Working Draft 08 July 2010:
Definitions
· Authoring tool
· the numbered items look like "notes" which further explain the
definition. They should be labeled Note 1, Note 2, etc.
· The examples include "debugging tools for web content". I don't
understand how debugging tools can be considered an authoring tool.
· authoring tools it includes email clients. If an email client
supports accessible we content authoring do we know that the mail format
preserves the accessibility information that would be prompted for in an
email authoring tool? Such as:alt text, ARIA semantics, table structure,
keyboard navigation.This applies to other document formats.
· Reference to blogs, Wikis, and content management systems. Most
blogs, wikis do not currently support ATAG 2.0 . It is important to state
how they can comply with ATAG checkpoints, and this may require s browser
plug-in.  Therefore, a browser plug-in must be an acceptable authoring tool
component.
· Web content management systems use Java-based content editors to test
content for WCAG compliance. Standard Java HTML editors only support HTML
3.2. So, somewhere there  needs to be a statement to ensure that authoring
tools accessibility analysis can fully support the host language.

· view
· The numbered items in this definition look like additional terms. In
fact, there are links from the document to the terms in the numbered list
yet they don't make sense unless you read the parent definition. For
example, Guideline A.2.2 rationale links to the term "editing view" but the
bullet "editing views are editable" is not a sufficient definition to
understand what the term means in the context in which it is used. Creating
separate terms in the glossary with definitions that stand alone and also
reference the more general term would be a better approach.

· programmatically determined (programmatically determinable)

· (Blocking issue) do not  agree with the definition of
programmatically determined. It is inadequate and should not be limited to
"platform accessibility architecture." Platform accessibility architecture
is also inconsistent with the U.S. 508 refresh.  Do not want to mislead
people to thing that only what is available in the platform accessibility
architecture can be used. Definition must refer to platform accessibility
services and platform accessibility services to be any recognized
accessibility services layer supported by assistive technologies that
support full interoperability with web content technology capable of
supporting WCAG 2.

· 508 refresh refers to platform accessibility services. Platform
accessibility services should include MSAA and IAccessible2 together.  Both
are referred to in the ARIA and HTML 5 API mapping documents. There is no
issue exposing access to a DOM as part of being programmatically
determined. The DOM does not have to be a W3C DOM. However, the definition
of platform accessibility architecture refers to a single document object
and not a document object model. In IE ATs access information from a W3C
DOM API and another DOM API that provides things like gaining access to the
computed style of a document object within that model. So, these
definitions do not adequately address what ATs need or are using to gain
access to information.

· CSS styling for final format is accessed through non W3C DOMs. IE
actually has two DOMs (one w3c and another of their own design). The one of
their own design has a getComputedStyle method on DOM elements. When
solutions use none standard (publicly recognized accessibility services)
that are needed to meet this requirement they should be documented. Reason:
an authoring tool needs to be able to prove that they can actually meet
ATAG. I don't see that here.


Understanding Levels of Conformance

· Note 4 in the definition of authoring tool indicates ATAG 2.0 is not
intended to be applicable to simple text editors. Therefore, "text editors"
should be removed from the following bullet: "whether it is possible to
satisfy the success criterion for all types of authoring tools  that the
success criteria would apply to (e.g., text editors, WYSIWYG editors,
content management systems, etc.)"
· In this sentence defined "proportionally greater" as this is vague:
In other words, the user interface issue must cause a proportionately
greater problem for authors with disabilities than it causes authors
without disabilities and must be specific to authoring tool software, as
opposed to software in general.


Part A: Make the authoring tool user interface accessible
· Applicability Notes
· Scope: appears that this applies to all views of the content being
edited. But authoring tools support multiple content formats, some of which
might not support accessibility. Is this a problem?

· A.1.1 and A.1.2 refers to Web-based and non web-based authoring
tools. Web-based is not clearly defined. When stating web-based do you mean
W3C document standards or do you mean that to include any web delivered
standard such as Flash, Flex, Silverlight, etc.?

· A.1.1 Web-based functionality: For web-based UIs, some of the
subsequent requirements modify WCAG 2.0 requirements. Has the work been
done to determine it is even possible to comply with A.1.1 (comply with
WCAG) AND comply with all of the subsequent requirements that are tweaks on
WCAG 2.0 requirements? If the rationale is that these things are needed for
non-web-based functionality, then the provision should be scoped to
non-web-based functionality. For example, why is A.3.2.2 needed for
web-based content when it also has to comply with WCAG 2.0 via A.1.1?

· A.1.1 and A.1.2 refer to web content but they don't state that the
web content be supported by at least one user agent to be consistent with
UAAG 2. If you don't have this stipulation then the user will be unable to
use the web content. Somewhere in ATAG this does need to be stipulated.

· A.2.2 Rationale: an example of "information about the end user
experience of the web content being edited" would be helpful

· A.2.2.1. doesn’t appear the vehicle for doing this is fully
addressed. For example, when authoring a mashup what vehicles are
stipulated to determine when alternative content is available to meet a
specific user’s needs and how are users needs conveyed through the
authoring tool. Example: a google map has a linear text-based driving
direction alternative. Today, web content mashups do not do this. A
standard meant to address this is the IMS Access For All Specifications.
Concerned with the definition of Programmatically Determined.


· A.2.2.2 Access to text presentation: The use of the word "and" in the
sub-bullets is unnecessary as the provision wording is clear that if any of
these presentation characteristics are supported, they must be
programmatically exposed.

· A.2.2.2 We are concerned about the definition of Programmatically
Determined. Programmatically Determined Definition - a blocking issue The
document must support platform accessibility services and that needs to be
re-defined. This problem is pervasive throughout the spec and
implementation guidance.

· A.2.3.1: Since A.3.6.2 requires respecting the platform display
settings, it seems to override any other way of allowing authors to set
their display settings. So A.2.3.1 seems to be reduced to a requirement
that the tool respect the platform display settings without affecting the
Web content to be published. Seems like this could be simplified by just
rolling the "independence" requirement in A.2.3.1 into the "platform
settings" requirement in A.3.6.2. At a minimum, A.2.3.1 should reference
A.3.6.2 as A.3.6.2 currently references A.2.3.1.
· A.3.1.2 No keyboard traps
· a) requires a keyboard way to exit all content that can be entered
using the keyboard. Is this always possible for authoring tools? For
example, say you have an authoring tool that allows the addition of third
party UI widgets. If you drag insert one of those widgets into the content
you are editing and move keyboard focus to it, who now owns the keyboard
focus? The widget or the authoring tool? If it's the widget, then how does
the authoring tool guarantee that you can exit the widget with the
keyboard?
· b) requires a documented keyboard command that will always restore
keyboard focus to a known location which seems like a good requirement,
however, the example of "menus" doesn't seem to accomplish the goal. If
your keyboard focus is trapped and you move it to the menus then back to
the document, it should go back to where it was before you put it on the
menus. So it would still be trapped. Suggest that the requirement be to
have a keyboard command that moves focus to a known location within the
content being edited.
·	A.3.1.3 Keyboard shortcuts: This is an advisory, not a requirement,
in WCAG 2.0 because it's just not testable in a useful way. As worded, you
would technically pass this SC if you have at least two keyboard shortcuts
but whether you have actually provided enough keyboard shortcuts to make
something usable is highly subjective or requires extensive user testing.
This will be a source of controversy with regards to compliance so it
should mirror WCAG 2.0 and have this be an advisory technique for meeting
A.3.1.1.
· A.3.1.3., A.3.1.5  The techniques refer to all mobile devices having
keyboard shortcuts. Is that accurate? Appears to be desktop centric, and
not supportive current mobile devices.
· A.3.2.1 Data saved: What does "submitted content edits" mean in a
non-web-based authoring tool?
· A.3.2 What happens if the authoring tool give the author the ability
for the author to set the refresh rate of the page? This is something the
author has set. Does this require warnings to the author when during a test
run the time is about to expire?
· A.3.4 Need to improve the definition of structured web content. "
Structured web content is content that includes machine-readable internal
structure (e.g., markup elements), as opposed to unstructured content, such
as raster image formats or plain human language text."
· Not all markup elements are structural. A button is not a structural
element. Structural elements are those that define structure for other
content elements: landmarks, tables, headings, listboxes, lists, tree
widgets, etc. Structural elements provide context in a defined layout or
order. An example would be a containment model.

· A.3.4.1 seems pretty subjective to be a Level A requirement. Looking
at the "implementing" guidance to understand this better, I would not agree
with the table "element" example, at least not for a source code view. If
you select a table "element" in a WYSIWYG view, the entire table would be
selected so "delete" should delete the entire table. But in a source code
view, I don't agree that if you delete the table element you should delete
all of the children of that element. The tool might highlight the error
somehow but I don't think tools should be making decisions to delete more
than the author deletes in a source code view. The example should be
changed and this requirement should be moved to AAA because of the
subjective nature of it.
· A.3.5.1: the sub-bullets don't need "and" at the end of each one. And
is implied by the wording of the parent provision because it doesn't say
"one of the following"
· A.3.5.1 Most browsers support text search and type ahead capability.
Would this satisfy the checkpoint? If so, why is it not in the
implementation section? Why do you confine searches to the editing view in
this situation? Have you spoken to UAAG about requiring the feature of text
searching. This would remove the burden from the author for web content.
· A.3.6.1 Saving authoring tool display and keyboard settings. This
seems onerous if you are doing rich web applications. It means you need to
have some sort of RESTful service to stash this information. Local Data
Storage does not show up until HTML 5 for the web. I am not aware of a web
email clients (rich text editing capability) that supports this today.

·	A.3.6.2 Web pages do not have access to keyboard control settings so
what happens when you have a web page that acts like an authoring tool? At
best you could implement best practices for a given platform but if
customization goes on you are out of luck. Browsers have security walls put
up to prevent you from asking OS specific information. Is there a plan to
address this issue?

· A.3.7.1 You need a provision for gestures. I.E. devices that support
only gestures should provide a discrete gesture that does this. That
gesture should be operable by devices that support people with mobility
impairments. Also, you are referring to UAAG 1.0. This document is so
dependent on UAAG that I think UAAG 2.0 and ATAG 2.0 need to come to last
call together. UAAG 1.0 is 8 years old.

·	A.3.7.2 Preview" why does sub-clause a require "third party" user
agent? Does this mean that Microsoft authoring tools have to use Firefox,
Opera, or Safari instead of IE in their preview mode?

· A.4.1 Do you have a limit to the number of Undos the author needs to
support? One undo is not very helpful.

· A.4.2.2 Does this require statements of UAAG conformance?

Part B: Support the production of accessible content
· Applicability Notes, bullet 2: I don't understand this example: "In
contrast, for automatically-generated content, Part B continues to apply
after the end of the authoring session. For example, if the site-wide
templates of a content management system are updated, these would be
required to meet the accessibility requirements for automatically-generated
content."
· B.1.2.1 and B.1.2.3: the parenthetical (WCAG 2.0 Level A) and (up to
WCAG 2.0 Level AAA) are critical to the provisions and should not be in
parentheticals.
· B.1.2.2 This is too blind user focused and is an unrealistic request.
A comment will not be seen by a sighted user. If you make it visible (to
all users then it impacts the output negatively). I don't think this is a
valid requirement to be included. It is too weak and the right solution
would be to get the document author that owns the target to try to expand
their accessibility support. Most authoring tools today don't try to stuff
un-renderable content in the exported file format. This is also fraught
with problems. Let's say there is a describedby relationship to non-visible
content used for help information and the target system does not have a
means to reference it. If you put the comment in the targeted export a
screen reader may not know what it is associated with. This would in
essence be orphaned content in the exported document format.


· B.1.2.3 - Why is the AA requirement to preserve accessibility
information up to WCAG 2.0 Level AAA? It should only be up to Level AA. If
Level AAA is required, there should be another provision.
·	B.1.2.2 and B.1.2.4: the sub-bullets don't need the word "or" at the
end as it is clear from the parent provision that only one of these is
required.

· B.1.2.4 Most if not all information is accessibility information. If
I export a file to PDF are you going to interrupt the user ever time it
runs into an unsupported feature in the target document format? This seems
unrealistic. For example, text is important to accessibility as is alt
text.  I think accessibility information needs expansion for that reason.
Also what about labels and live region support - any accessibility
property.

· B.1.3 The Rationale: is not a complete sentence. (must impose, should
impose, etc.) This section refers to repair tasks but does not really
address what the repair tasks are other than to say that the generated
content must be compliant. Seems confusing.

· B.1.3.1: needs to be clarified that the tool must provide a mode of
operation that complies with this requirement. It should be allowed to be
turned off and it should not be required to be the default at Level A.
Requiring it by default would be okay at Level AAA.
· B.1.3: unclear what "prior to publishing" means. What if I'm using
Microsoft Word to create a document, then I save it as HTML. That's not
publishing. It's not "published" until I upload it to my website. Does this
requirement only apply to tools that include publishing? Or would it mean
that if I use one tool that generates automatic content but doesn't publish
and then FTP  to upload files to my website, my "set" of authoring tools is
non-compliant with ATAG? Per the definition, ATAG applies to all of the
tools used in the process.
· B.2.1.1 Showing a warning every time seems intrusive to the author.
This is like Vista's constantly asking you if you want to do something.
Should this just be documented in the product? Also, I am a bit surprised
by the fact that the definition of Web Content Technology does not include
things like Silverlight or Flash given that WCAG 2 applies to anything
delivered over the web. It seems like the W3C is not being consistent here.
· Also, I am a bit surprised by the fact that the definition of Web
Content Technology does not include things like Silverlight or Flash given
that WCAG 2 applies to anything delivered over the web.  W3C needs to be
consistent.
· B.2.1.2 This is very good but it needs to be synched with the
definition of accessibility information otherwise there will be
inconsistencies. I would also point out that both ARIA and HTML 5 refer to
well formed content such as Grid must have a row and a row must have a
gridcell. Shouldn't authoring tools deal with supporting accurate
structural information?

· B.2.2.1: I think "manual checking" is the wrong term here. The
authoring tool is not doing the manual check but rather providing guidance
to the author in performing the manual check. The "checking" should only be
required where automated checks can be performed.

· B.2.2  this should be a configurable item achieved through the use of
a plug-in. Also, has the working group considered assisting authors who are
creating DHTML content where accessibility changes dynamically during
application authoring? This seems to be a gap in that authors may not be
aware of.

· B.2.2.4 Determining where accessibility issues are can be problematic
with dynamically generated content.

· B.2.2.6   Difficult to have a web email client or a wiki provide a
status report on accessibility of dynamic content.  There is value, but
this is a significant requirement, should be AAA and configurable.

· B.2.2.7 Need more concrete examples of using metadata here. Metadata
is very abstract.

· B.2.4 Techniques should cover:

· alt text for graphics

· labels for widgets (aria-label, title attribute) and standard input
controls

· descriptive text as optional (longdesc, aria-describedy, etc.)

· B.2.5.1 There should be an accessible template alternative for
components. Some templates may be from third parties and may be
inaccessible.

· B.2.5.9 For content such clip art it may be inaccessible. The author
should be able to provide the alt text to make it accessible. So, the
source template may not comply but it could be fixed. I don't know that you
would have to always require that the template be WCAG 2.0 compliant to
start.



Conditions on Conformance Claims
· bullet 4: BLOCKING ISSUE: we raised an issue last time about anybody
being able to make a claim even for stuff they don't own. What if a
government enacts procurement regulations requiring ATAG compliance, we
provide a compliance statement on one of our products that differs from
what a journalist somewhere publishes about our product? The journalist
might falsely claim that our product is compliant. Would the customer then
hold us liable? Or conversely, we may be claiming compliance due to some
particular situation about how the product is going to be used by this
customer but the journalist claims it is not compliant. We might lose the
sale.
· Comment "It seems weird to me that anyone can make a claim. Of course
you can't prevent it but odd that the W3C would endorse it. If it stays in
there, then we need to insist that the claim has to include information
about who is making the claim. We don't want to be held liable for a claim
that someone else might make about our products." The claimant's name has
now been added but I still don't like it.
· bullet 5 seems especially problematic for us where we have bundled
third party components that are not licensed to the customer by IBM:
"Claimants are solely responsible for the accuracy of their claims
(including claims that include products for which they are not responsible)
and keeping claims up to date."
Sue Nichols

Phone: (720) 396-6739 (t/l) 938-6739
ssnichol@us.ibm.com
IBM Human Ability & Accessibility Center
http://www.ibm.com/able