FW: IBM Feedback: ATAG 2.0 W3C Working Draft 08 July 2010

Hi all,

The IBM comments have been added to the comment table with some initial reaction.

Cheers,
Jan
--
(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

From: Sueann Nichols [mailto:ssnichol@us.ibm.com]
Sent: September 15, 2010 9:01 PM
To: Richards, Jan; w3c-wai-au@w3.org
Subject: 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