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

Hi all,

A note to AUWG: The external comments on ATAG 2.0 are sent to a different mailing list “public-atag2-comments”and are archived at: http://lists.w3.org/Archives/Public/public-atag2-comments/


Thanks to Peter at Oracle for sending these along. I have marked each with a comment identifier, added them to our table of comments and added an initial comments for each (marked by “JR”).

> OC1: 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.

JR: Section 508 is U.S. legislation/regulations, so W3C can’t simply refer to it. That said, it makes sense to examine any points of conflict between ATAG 2.0 and Section 508.

> With regards to items in Part A for a web-based tool:
> OC2: -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.

JR: There may be some confusion here. A.1.1 refers to WCAG 2.0, which covers much more than support for assistive technology. A.1.2.1 includes links to information on accessibility APIs but also covers accessibility issues such as keyboard navigation, colors, etc. that are included in the standards or platform conventions.


> OC3: -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.

JR: The WG suggests this rewording: “If content is rendered in editing-views, recognized alternative content can be programmatically determined.”


> OC4: - 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.

JR: Perhaps: “If an editing-view modifies the presentation of web content to provide additional information to authors, then that additional information can be programmatically determined.” (same proposals as for MS6)


> OC5: -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.

JR: Agreed.


> OC6: - 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.

JR: There will always be a tension in some UIs between shielding authors from unnecessary technical details and allowing them to make use of those details if they wish. WG needs to discuss.@@


> OC7: -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.

JR: While all users benefit, people who have difficulty using the keyboard benefit more. I could see dropping “search all editable” for “include alternative text in search”.


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

JR: Some are aided by the ability to have multiple sets of preferences (e.g., because their vision fatigues easily).


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

JR: We have considered that in the past, but decided that the point of a Preview is to experience authored content the way it will be experienced in “real-world” user agents. But perhaps a AAA requirement would be to let the author use any user agent they wanted.


>  OC10: -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’.

JR: Maybe we take out the word workflow and say: “Authors with disabilities need the same opportunity to check their work.”


> OC11: -A.3.7.2 – As written, there is no requirement that the 3rd 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.

JR: re: 3rd party tools, I agree this should be changed – it was never the intention to disallow a company’s own tools. I think Preview should rule out thumbnails.


> OC12: -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.)

JR: Any actions. I don’t follow the example.


> OC13: -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’?

JR: WG needs to discuss. I think it should stay.


> OC14: 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.

JR: “programmatically determinable.” Is a property of many things, not just things related to accessibility. E.g. the height and width of images can be programmatically determined. By “human judgement” we always mean decisions by the human author.


> OC15: 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.

JR: Requires WG discussion.


> OC16: -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.”

JR: OK


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

JR: It’s because we wanted to be flexible around the timing of when the tool addresses the issues. For example, it should be ok for tools to let users drag and drop images into a document without immediate accessibility prompting, as long as the issues are queued for author attention before publishing. That said, if it’s a wiki, the act of submitting content to the tool is also the act of publishing, so it’s something we need to look at.


> OC18: -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.

JR: The definition of Technology encompasses format. The term was worked out with WCAG-WG and UAWG so I’d prefer not to change it.


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

JR: I disagree, “typical” is hard to test.


> OC20: -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.

JR: Maybe we should be more clear that we mean a text description or link to alternate accessible version.


> OC21: -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?

JR: Yes, that’s the minimum requirement. Of course, it wouldn’t be a very usable implementation and hopefully market pressure would move things in the direction of automation.


> OC22: -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?

JR: Perhaps: “Help Authors Decide: When manual or semi-automated checks require authors to make a decision, instructions are provided that describe how to make the decision.”


> OC23: -B.2.2.7 – We recommend making this Level AAA.

JR: The group decided it was Level AA.


> OC24: -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.

JR: A checker without any further information isn’t going to help most people. Perhaps they could be framed as suggestions, like with a spell checker:  “repair assistance is provided” could be: “ repair suggestions are provided.”


> OC25: -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.

JR: Perhaps: The authoring tool does not attempt to repair alternative content for non-text content using only text values that are equally available to user agents (e.g., do not use the image filename).”


> OC26: -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.

JR: Except that authors may sometimes view accessibility as “extra work” so it’s more important to simplify time-intensive accessibility tasks.


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

JR: We should add some advice on this to the Implementing doc.


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

JR: Agreed – for developer provided templates.


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

JR: Agreed.


> OC30: -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.

JR: Agreed.


> OC31: -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.

JR: Perhaps “comparable prominence”.  It is absolutely difficult to test but I think everyone would agree that a spell checker that underlines words in text has a much higher prominence than a utility that is activated from a third-level menu item.



--
(Mr) Jan Richards, M.Sc.
jrichards@ocad.ca | 416-977-6000 ext. 3957 | fax: 416-977-9844
Inclusive Design Research Centre (IDRC) | http://inclusivedesign.ca/

Faculty of Design | OCAD University