Oracle comments on ATAG 2.0, Working Draft 08 July 2010

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