Fwd: Oracle comments on ATAG 2.0, Working Draft 08 July 2010

It hasn't shown up on the public comment list yet.

-------- Original Message --------
Subject:  Oracle comments on ATAG 2.0, Working Draft 08 July 2010
Date:  Mon, 13 Sep 2010 12:11:45 -0700
From:  Peter Wallack <peter.wallack@oracle.com>
Organization:  Oracle Corporation
To:  public-atag2-comments@w3.org, jeanne@w3.org



Oracle Corporation thanks you for the opportunity to respond to the
Authoring Tools Accessibility Guidelines working draft dated 08 July
2010. We appreciate that a lot of effort has gone into this draft, but
feel that in some areas additional changes are needed.

We appreciate the distinction being made in Part A – making the
authoring tool itself accessible, versus Part B – making the output of
the tool accessible; however, we feel that the Part A information needs
finishing. The information in Part A is very good for when the tool is a
web-based tool, since that is the expertise of the group. Our area of
concern with this is in the situation where the tool is not web-based.
An effort was made to address this, but it has been done in a way that
has many potential problems. For example, when compared to current and
proposed U.S. Section 508 standards for ‘software’, what is currently
presented ranges from being a subset of those standards, to possibly
presenting standards that might be in conflict. Our recommendation is
for Part A to address only web-based authoring tools (and perhaps just
refer to Section 508 for non-web based if you speak to that at all).
Failing that, make all of the non-web-based provisions aspirational or
advisory.

With regards to items in Part A for a *web-based* tool:

-A.1.1 – We recommend renaming this to “Ensure web-based functionality
supports use by assistive technologies” since the information in the
line “Implementing A.1.1” is about accessibility APIs. Additionally, if
one meets a broad guideline requiring that ‘functionality is accessible’
then one can reasonably infer that all subsequent guidelines would also
be met. As such, it creates a tension similar to the Functional
Performance Criteria and Technical Standards present in U.S. Section
508, which should be avoided.

-A.2.1.1 – We find the guideline to be generally confusing. The word
‘provided’ in the guideline also complicates it, since it may be
interpreted to mean that the tool must supply the text, perhaps as a
default value. Was the intent that the tool ‘expose’ current content? We
recommend this item should be removed or made non-normative.

- A.2.2.1 - As currently worded, it is not clear whether it is the
visual (or otherwise) representation of the additional information, or
the semantic meaning of the additional content, that must be
programmatically determinable.

-A.2.2.2 – The minimum list is incomplete; for example, it should also
include text-background color or text highlighting color. Also, the
Implementing information refers to non-web based information and should
be removed.

- A.3.4 – It is not clear to us that exposing content structure
necessarily ‘enhances’ or ‘simplifies’ navigation and editing. In fact,
many of our authoring tools are specifically designed to shield the
author from the underlying structure. We recommend that this guideline
be made advisory.

-A.3.5 – It is not clear that this is specifically an accessibility
requirement. Furthermore, it is not clear how one could implement this
in practice, for example if the target of the search may be rendered in
multiple user interfaces including modal dialogs. Lastly, ‘text that the
authoring tool can modify’ is too broad, because some of that text may
only be available at ‘runtime’, in which case it would be the
responsibility of the user agent to account for this feature. We
recommend that this guideline be made advisory.

-A.3.6.3 – Regarding loading multiple sets, we question why this is an
accessibility issue. We recommend removing it.

-A.3.7 – We wonder if there should be a Level AAA requirement that the
preview be accessible.

-The Rationale for A.3.7 – Regarding the last sentence “Authors with
disabilities need to be able to follow the same workflow”, we feel that
this may not necessarily be the case. They need to follow ‘a’ workflow,
which is supported, documented, etc. but it may not be the ‘same’ as an
author without a disability. Or perhaps a ‘workflow of similar effort’.

-A.3.7.2 – As written, there is no requirement that the 3^rd party user
agent conform to UAAG. Was that the intention? It is also unusual that a
company would not be allowed to use their own user agent. Lastly, for
clarity, the definition of ‘preview’ should discuss renderings such as
thumbnails.

-A.4.1.1 –By ‘Authoring actions’, is this referring to any action, or
only those that are ‘significant’, ‘harmful’, etc.? Is a workflow in the
authoring tool that a user must explicitly save an example of ‘undo’?
(the author could always choose to not save and open the last-saved file.)

-A.4.2.1 – Regarding documenting “all features” we feel this is too
broad. This is a requirement for all users, not just people with
disabilities so we feel it isn’t applicable to ATAG. Even with narrowing
to “all ‘accessibility-related’ features” this could still be very
broad. For example, why would features that are programmatically
determinable, such as keyboard shortcuts, need to be ‘documented’?

In Part B, we have a concern with the use of the term “accessibility
information” and wonder if the correct term is really “programmatically
determinable.” The term “accessibility information” is too broad and by
changing the term it helps to narrow what is being referred to. We are
also concerned with the phrase “human judgment” that is used in many
places. What are your expectations for this? It seems to be leading to
the tool must almost supply artificial intelligence to know what to do.

Often part B has an all-or-nothing approach to producing accessible web
content where level A is the only level where something can be met. We
would suggest that many of these could benefit from an approach where
the level A or AA guideline allows a timely, accurate, complete and
efficient mechanism to complete a task. A corresponding level AAA
guideline could then be introduced where ALL of the methods to produce
content provide the same benefits.

-B.1.2.2 – Regarding entry “b”, the loss of recognized accessibility
information does not necessarily result in accessibility problems. We
suggest rephrasing as “authors are warned that due to the transformation
there could be accessibility problems in the output.”

-B.1.3 – What is the significance of “prior to publishing” in each
guideline?

-B.2.1.1 – The sentence “If the authoring tool provides the option of
producing a web content technology for publishing…” We recommend
replacing the word “technology” with “format” since the output of the
tool isn’t a technology.

-B.2.1.2 – We feel this should be reworded to “At least one typical
method to…” instead of “Mechanisms that…”.

-B.2.1.3 –The text as written can work in some situations such as if you
import a picture and add alt text to it, but this item doesn’t work more
broadly without becoming confusing. It really depends on the technology
in question. An example is OLE-style situations or importing a movie
that isn’t accessible. No matter what the tool does, it can’t make the
movie accessible, it can only describe what is broken about it. It comes
down to one tool cannot modify the content of another tool. We do not
have proposed text for how to correct this item, but wanted to raise the
concern.

-B.2.2.1 – We are a bit confused by the meaning of this entry - it seems
to read overly broad. Can the criteria of “provide checks” be met by
just documenting how each standard could be manually checked?

-B2.2.3 – The guideline is very broad. While the two examples are clear
(manual & semi-manual checks), it is unclear to us in what other
circumstances instructions are to be provided to authors around
“deciding whether [a check] is correctly identified”. We recommend
restricting this Level A guideline to only those two situations, or at
least to clearly enumerate the other situations.

Please also clarify if linking to the relevant WCAG2 guidelines would be
adequate to meet this guideline for technologies that are covered by WCAG2?

-B.2.2.7 – We recommend making this Level AAA.

-B.2.3 – Assisting in repair implies prescribing a solution that may not
be the only way to do it. There is a concern here that this ultimately
could lead to liability, and/or stifling creativity.

-B.2.4.3 – The wording of this item is really difficult to understand.
It takes many times through to get an idea of what is being asked for.
Recommend rewriting.

-B.2.4.4 – We recommend making this Level AAA as this is applies equally
to non- accessibility related content and moves into a product usability
feature.

- B.2.5 Several standards mention a ‘recorded accessibility status’, but
no advice is provided on how this is to be measured.

-B.2.5 – We recommend adding a Level AAA where all templates are accessible.

-B.3.1.1 – We suggest that things like lists and tables should be added
to the examples since these are challenging situations.

-B.3.2.1 – We recommend dividing this into three entries similar to
B.3.1.1-B3.1.3 having one entry for each of the Level A, AA and AAA. For
example, for Level A all WCAG 2.0 A accessibility features turned on by
default.

-B3.2.4 – Because there are a variety of prominence levels for the
examples given it will be very subjective which to choose. How we would
highlight markup is very different from a spelling issue. This makes the
item very subjective and hard to test.

-- 
Regards,
Peter

Oracle logo <http://www.oracle.com>
Peter Wallack | Accessibility Program Director
Phone: +1 650 506 2272 <tel:+1%20650%20506%202272>
Oracle Corporate Architecture Group
500 Oracle Parkway | Redwood Shores, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment

Received on Monday, 13 September 2010 20:14:24 UTC