Comments

Comments on the May draft

Definition of authoring tool:
      text editors should not be included. We discussed this at length in
      TEITAC and specifically excluded them in the definition:
         Any software intended to create or modify electronic CONTENT for
         publication in one or more formats that support compliance with
         the user interface and CONTENT provisions.
            Note:  Simple text editors that can only create or modify
            content in conforming formats by directly editing the code are
            not considered authoring tools under this definition.



The Notes on the Definition of what ATAG 2.0 applies to should include

- debugging tools for web delivered content


Mozilla is funding a Firebug extension that assists the author in debugging
rich internet applications for accessibility - in particular WAI-ARIA. This
is a first for the industry and is essential.


       Organization: Since an effort was made to organize the requirements
      according to WCAG principles, why not also put them in the same
      order?
         Perceivable
         Operable
         Understandable
         Facilitating access by AT

 The ATAG document says this:
Guideline A.1.2 [For the authoring tool user interface] Ensure that
non-Web-based functionality is accessible. but the techniques document says
this:
Guideline A.1.2 [For the authoring tool user interface] Support
interoperability with assistive technologies. [Return to Guideline]

If I ignore the fact that the Guideline and techniques don't match (since
they are from 2008 perhaps they haven't been updated to reflect changes in
the ATAG guidelines?) , I really don't understand what

 A.1.2.1 - A.1.2.3 - this is creating another standard for software
accessibility which creates fragmentation and is not the direction in which
we want to go. ATAG 2.0 should just require that the non-Web-based software
comply with a recognized software accessibility standard and then list the
known possibilities: ISO 9241-171, Section 508, EU M376. Since these
change, perhaps they should be listed in the techniques and not in the
normative document which is difficult to update. WCAG submitted a similar
comment I believe.

A.1.2.1 Non-Web-Based Accessible (Level A): Non-Web-based authoring tool
user interfaces follow (and cite in the conformance claim) the "Level A"
requirements of standards and/or platform conventions that benefit
accessibility. The "Level A" requirements are those that are functionally
equivalent to WCAG 2.0 Level A success criteria. (Level A)

means?  Does this mean an authoring tool author has to figure out what
parts of WCAG the platform supports? That seems somewhat hard to test -
without some sort of definitive mapping between the platform capabilities
and WCAG 2.0

Guideline A.2.1 [For the authoring tool user interface] Provide access to
alternative content in the Web content.
This is about non-text content - why not state that?   Provide access to
text alternatives for any non-text content in  rendered  views of Web
content.


Applicability Notes in  section A.2.1: Editing view should point to a
formal glossary item and not text within a definition for a view.

A.2.1.1. The definition of alternative content is inadequate to address
this guideline. you may in fact have a flexible system which may require
full equivalent replacements for the content defined by user preferences
such as a table or accessible datagrid equivalent for a complex
visualization. The system may in fact generate alterative content that
would be more accessible to an individual user. Although WCAG does not
address this ATAG certainly could while still supporting WCAG. How the user
specifies this equivalent will be based on their need. ... Think Access for
All or ISO DRD/PNP. The ATAG chair will know what we mean.


Guideline A.2.2 this sentence is very confusing to me:
Authors need access to the information signified by presentation added by
the authoring tool.
what does "signified by presentation" mean?  I think the definition of
presentation is problematic.  The WCAG definition of "rendering of the
content in a form to be perceived by users" makes sense but substituting
"authors" for "uses" doesn't feel correct to me.

Perhaps augment the guideline a bit:  Provide programatic access to (all
authoring  specific) information in the editing view.
Then the description becomes:  Authors need access to all authoring
specific information added by the authoring tool.


      ASW A.2.2 - agree with Rich that the wording needs to harmonize with
      WCAG; i.e. use "programmatically determinable" instead of "available
      via the platform"

      A.2.2.1 - can only do this if the platform supports it. IA2 has an
      attribute for underlined text but I don't see a way to communicate
      via the platform that underlining means "misspelled word."

A.2.2.2

The definition of "available via the platform" is inadequate. The API use
may not be included with the platform but may be provided separately. The
Accessibility API may not be included with the platform but may in fact
augment the accessibility of the platform - such as through the use of
IAccessible2 or Microsoft Office DOM interfaces.

platform accessibility architecture: This is also limiting. The definition
limits the author to standard accessibility API included with the platform
and a DOM object. The entire ARIA and ODF accessibility efforts on Windows
would not have been possible without IAccessible2. And at this time UI
Automation is not supported by the major assistive technology vendors.
While I am quite sure Microsoft will get there it is not the case today,
therefore this definition will not yield the appropriate results. We are
working to assist Microsoft to ensure they do at least for IE.
Consequently, there is a problem with your definition of platform. The
entire ARIA effort was initiated based on an API that was not part of the
native platform on Windows as well as a part that was - MSAA. IAccessible2
should be included.

So, the suggestion should be to include publicly recognized, and tested
accessibility API that are supported by assistive technologies and which
operate on the target platform.


Then in this description of guideline A 2.3
Rationale: Some authors need display settings that differ from the
presentation that they define for the published Web content (e.g., an
author may zoom an editing view in order to modify text that will appear
small by default to end users).
it seems that "presentation" is referring to the rendering in a form
perceived by the user rather than the author.

This guideline seems confusing - how can a rendering be called WYSIWYG if
the rendering is using the authors specific display settings?  I understand
the rationale, the author needs to be able to perceive what they are
creating so tool needs to respect their preferences.  But, rather hard to
figure out from the current descriptions.

A.2.3.1

The definition of visual and audio display settings states nothing about
where they are set. These should reflect "platform" settings and
user-defined application settings (Firefox, Safari 4, IE zoom features).

A.3.1.1 You explain the rationale for keyboard access but don't explain why
you limit single key or modifier key+key access to these functions. Why
would you not include access to the authoring tool's menu, print, or search
functions. These are very important.

 Would a context menu that provides access to the required functions be
sufficient to meet
A.3.1.1 Important Commands: If the authoring tool includes any of the
following features, authors can enable key-plus-modifier-key (or
single-key) access to them (where allowed by the operating environment)
(Level A):
 since a context menu is a bit more indirect than a key+modifier or single
key access?


      A.3.1.1 - Most OS platforms have standard accelerator keys for these
      functions. If they don't, should we really require it for authoring
      tools? Seems like that would put the authoring tools out of sync with
      the platform?

      A.3.2.2 should be deleted as it duplicates and is more restrictive
      than WCAG 2.0 2.2.1.

I'm not sure how
A.3.2.3 Moving Targets: If a user interface component that accepts mouse
input is capable of movement (e.g., animated vector graphic), provide
authors with the option to stop the movement. (Level A)
relates to A.3.2 - since moving targets doesn't seem to have anything to do
with time limits.  Maybe A.3.2 should be more broadly worded.  I think the
original wording (from the techniques document Enable time-independent
interaction. makes more sense.

 A.3.4.1 The definition of structured element sets is too limiting. It
should not just in include organized elements. Headings are considered
structural yet in and by themselves they do not imply a collection of
organized elements. ARIA landmarks should be included as well. The
definition of structured element should be that of a significant semantic
areas of the page which in turn support the structure of the web page. You
might even refer to the WAI-ARIA taxonomy to see how we defined our
ontology for the structured elements.

      A.3.4.3 - what if the structured element set doesn't have a "heading"
      element? what if there are no headings in the content being edited?
      "Heading" seems very technology specific. WAI-ARIA has a concept
      called "landmarks". Moving focus to the previous landmark would be
      the same concept but not required by this SC because it's specific to
      "heading".

 Regarding A.3.4.3 Navigate By Headings: I think  you need to define
"heading"?
A.3.4.4 Navigate Tree Structures:   I would refer to a hierarchical
structure rather than a tree structure - hierarchical is a more generic
term to me.


A.3.4.3 Your definition of structured element sets would not appear to
include headings but it should.

A.3.4.4 Navigate by tree structure. This may be a bit narrow. In an Ajax
environment you may have elements owned by a parent but are not reflected
in the DOM. So, you might want to include owned: elements owned by the
parent but are not reflected in the tree structure



      A.3.4.4 - "structured element set" in this SC should be "hierarchical
      structured element set" because the relationships only apply to
      something that is hierarchically structured.


I don't understand the use of Web content here:
A.3.5.1 Text Search: Authors can perform text searches of Web content in
which all of the following are true (Level AA):
Shouldn't this apply to the editing views or content  in the tool? The
glossary implies that Web content is the output of the tool - that should
be covered in part B????

A.3.6.1 and A.2.6.2 - If these are configurable from the desktop are they
also require by the authoring tool?
- If authoring tools are required to be WCAG compliant, why are previews a
special case? It would seem that they should be subject to the same set of
rules.
- Why is there a reference to UAAG 1.0? Has the ATAG working group looked
at UAAG 1.0 and identified guidelines that if employed would be counter
WCAG 2.0 and ATAG 2.0 objectives or today's best practices? For example,
guideline 4.1 is outdated in UAAG. All user agents today provide full
magnification rather than just text which is much more accurate. Should you
still be require font size increases.

 I found this confusing:
Guideline A.3.7 [For the authoring tool user interface] Ensure that
previews are as accessible as existing user agents.
I understand what it means after I read the additional material but this is
a case where the definition of "previews" doesn't really help me to
understand this text.   I think you mean the authoring tool's rendering of
the Web content in a WYSIWYG manner must be accessible (and A.3.7.2
provides the accessibility requirements).   I don't think you should
compare to "existing user agents" as not all of them may meet the criteria
set forth in A.3.7.2.

How can you have an authoring session without an author available?
Author Availability: Any success criteria in Part B that refer to authors
only apply during authoring sessions when authors are available.

A.3.7.2 - agree with Rich that this is a little weird but not for the same
reason. First of all, principles A.2, A.3, and A.4 only apply to editing
views. So, the exception for previews is already there. And it doesn't make
sense to include preview requirements under a principle that applies
A.4.2.1 and A.4.2.2 - needs editorial work. When I first read it, I didn't
get it as all product features are required to meet part A. But then I
realized it's trying to say that if your product has implemented functions
in support of the requirements in Part A, you have to document those
functions

An example would help to clarify this:

B.1.1.1 Tool Choice of Technologies: Only accessible technologies are ever
automatically selected by the authoring tool. (Level A)
Guideline B.1.1

This seems to restrictive. An authoring tool may support include support
for all kinds of markup. If one markup, like SVG, which does not fully
support assistive technologies is chosen the whole rest of the tool fails?
Recommend that the author be given the choice of choosing only accessible
technologies. In that mode it should be considered to satisfy this
guideline -  unless there are none.

This section should also allow for the selection of equivalent alternatives
that are accessible. Take a Mashup authoring tool. A chart may be
inaccessible but a table equivalent may be acceptable. You might even take
into account user preferences.

The section refers to accessible Web content but the definition of
accessible web content refers to a particular level of WCAG. Why should an
ATAG 2.0 compliant tool support WCAG 1.0 when in fact the guidelines for
being ATAG 2.0 compliant require that the authoring tool meet WCAG 2.0
requirements? I disagree that this should include all versions of WCAG.

Need to make sure this can be tested.

Guideline B.1.2.3

There may be a situation when the target markup does not support an
accessibility feature of original content. For example, a document markup
may provide for short text equivalents and long descriptions on a drawing
object but the target document may not. There is nothing the tool can do
about it. So, the point is that you should allow some leeway.

Guideline B.1.2.4 Do you want to notify when the target markup does not
support an accessibility feature? This is a problem as it is not clear WCAG
2.0 specifies that web content is accessible but what if the host language
has a hole. For example the keyboard navigation problems in HTML 4.0 is a
problem. Authors can work around a lot of it by using anchor elements.
However, some document formats have more accessibility features than others
and WCAG does not quite address the deficiency. I am avoiding a reference
to particular document formats.

 Could Guideline B.2.1 Guide authors to create accessible content. be met
by prompting the author to run an accessibility checker tool (linked to or
provided with the authoring tool software)  before closing a document and
then relying on the tool to  provide a list of errors that need to be
fixed?  Wait, after I read this a few times I realized that a11y prompting
is only applicable if the authoring tool prompts for some information.
Thus, this wouldn't apply to a text editor.


The checking and repair guidelines are problematic to me.   You will allow
manual checking - which essentially means the tool has to do nothing but
provide documentation on how to make content accessible - but then require
support for repair?   Can assisting with repair be satisfied also by
providing documentation on how to make content accessible?   That seems to
let the tools completely off the hook.   It might allow a text editor to
pass but I don't think that a more sophisticated tool should be allowed to
get away with that - although I guess that is why we have different levels.
Hopefully the more sophisticated tools will conform to higher levels.  But,
I would hate to allow a tool like Dreamweaver to be able to claim level A
compliance and also a text editor like TextPad to also claim level A
compliance.


Guidelines under B.2.2

WCAG 2.0 is very vague on how to meet robust in terms of interoperability
with assistive technologies. This section should:

- Ensure that assisting authors in checking even as the document changes
dynamically even when script is used to change the document as you operate
it. This is a huge problem with today's tools
- Authoring tools SHOULD test that custom components in RIAs conform to
common design patterns. For example, if an author creates a tree widget it
should conform to ARIA best practices guides. At the very least this should
be a Level AA requirement. We recommend the ATAG group look at this web
site: http://www.openajax.org/member/wiki/Accessibility . Although this
site is in wiki form and not in what we would call cleaned up it should
give you some insight.


B.2.2.4 - help authors decide what?

      B.2.2.8 - until we have standards for such metadata, it should be a
      AAA requirement, not AA

Guideline B.2.4.2 the statement is made: During the authoring session, the
authoring tool can automatically suggest alternative content for non-text
content under the following conditions: (Level A)

The use of "can" would indicate this is not a MUST or SHOULD meaning it is
not required. Was this the intent?

Guideline B.2.5

This suggests that only accessible templates be allowed. Should this be
based on an accessible mode?

      B.2.5.3, B.2.5.5 - 2.5.8 - since most templates, clip art images,
      widgets, etc. are simply selected from a standard file directory,
      this would seem to indicate a requirement to attach the accessibility
      status to the file somehow. Since neither the file formats nor the
      file systems support that today, it seems like too onerous a
      requirement to impose at AA. This should be moved to AAA.

      B.2.5.3, B.2.5.5 - 2.5.8 - since most templates, clip art images,
      widgets, etc. are simply selected from a standard file directory,
      this would seem to indicate a requirement to attach the accessibility
      status to the file somehow. Since neither the file formats nor the
      file systems support that today, it seems like too onerous a
      requirement to impose at AA. This should be moved to AAA.

Guidelines B.3.2

While this is an excellent guideline it may be difficult for the ATAG
author to know when they are done in all scenarios as there are no tools to
assist them.

      B.3.3.1 - this may be a show stopper for some tool developers. In an
      enterprise type of content management system, I can see how you would
      want an administrator function to enforce this. But it seems
      unreasonable to require this of all ATAG A conforming tools. It
      should move to level AAA.

      B.3.4 - rationale doesn't make sense if B.3.3.1 remains at level
      A. :)

      I don't quite understand this requirement: "Whenever the claimed
      conformance level is published (e.g., product information website),
      the URI for the on-line published version of the conformance claim
      must be included." I have to include the URI of the claim in the
      claim itself?

      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.

      Why is ATAG going with the approach that you have to list every SC
      and declare whether or not it is satisfied or N/A? I guess that's
      what we are planning to do so no biggie for us but is inconsistent
      with other WAI groups.


Sueann Nichols

877-202-9272 (t/l)  930-0636
ssnichol@us.ibm.com
IBM Human Ability & Accessibility Center
http://www.ibm.com/able