Comment 1: SHOULD, MUST and MAY need careful review so that it is possible to determine what qualifies as valid markup and what the expected behaviors are when requirements marked as SHOULDs are not adopted.
Comment 2: For consistency with WCAG 2.0, consider using "text alternative" instead of "text equivalent." The rationale is that there are many situations where alternatives can't be truly equivalent to the original non-text content.
Comment 3: In some desktop applications, one item may have focus, but another may have secondary focus. For example, when you use Windows Explorer to browse the folders on a drive, the name of the current folder has secondary focus (e.g. gray background colour) while primary focus is somewhere in the files pane. (Another example of primary and secondary focus can be seen at http://library.gnome.org/devel/accessibility-devel-guide/nightly/gad-focus-examples.html.en.) How is secondary focus addressed? Or is this out of scope and should it be handled by the User Agent (i.e. should secondary focus be considered as just another managed state)? If secondary focus is covered by the 3rd paragraph in "2.3. Managing Focus", that isn't very obvious.
Comment 4: The distinction between "widgets", "user interface objects" and "user interface elements" is unclear.
Comment 6: The focused element should not be scrolled off screen? What if that is what the user needs to do, e.g., to consult some distant part of the page without losing his place.
Comment 7: When discussing focus management, the statement that all interactive elements should be focusable seems too strong. A complex widget may contain elements that never become directly focusable. They may not even become indirectly focusable if there are other ways to achieve their function, e.g., keyboard shortcuts.
Comment 8: Roles augment or override the semantics of an element. Will ARIA say when it augments and when it overrides? Will it be clear what the effect is of adding a role to different types of elements? Example: tree sample is built from list elements. Does it matter if it is built from divs, or table elements? Can I tell from this document whether it matters?
Comment 9: Advice about trees that are not completely represented in the DOM seems a little odd. AT will need to support two different ways of expressing the same relationships. And it still seems possible that you will need ARIA-OWNS, depending on how the tree is implemented structurally.
Comment 10: Step 4 needs more implementation detail - it is meant to be an example.
Comment 11: It seems that only rows are expandable in a grid. Is there a reason that columns should not also be expandable?
Comment 13: The note at the end of the text equivalent computation is somewhat confusing and it's not clear whether it applies only to item 3 in the preceding list or to all items in the list. Please clarify what is meant here so that it can not be interpreted to mean that calculated text equivalents should not have structure.
Comment 14: Is this consistent with how text nodes are built in HTML, both in practice in current browsers and also under HTML 5? Perhaps this should be covered in the Implementors Guide or API mapping tables?
Comment 15: Additional contribution of user-entered data. Shouldn’t this be the AccValue rather than the AccName?
Comment 16: Is it really a good idea to use rendered text instead of the DOM? This creates yet another interpretation of the html, and seems like it could lead to subtle bugs.
Comment 17: Some examples of markup and the resulting AccName would be really useful here.
Comment 18: section 4.3.1 contains a note that authors should not use abstract roles in content. The lists in 4.3.2 (user input widgets) and 4.3.4 (document structure)
contain a few roles that are marked as abstract but that would be useful in content, especially section and sectionhead. Why are these abstract?
Comment 19: We would like to see (possibly as an appendix) a table that lists all concrete roles and all properties and states supported by each role.
Comment 20: What is the difference between and abstract and a base role. What do base roles add?
Comment 21: HTML 5 uses "dialog" to mean something entirely different than ARIA (In HTML 5, a dialog between two speakers, as in a dramatic script).
Comment 22: Why is application a landmark role instead of an application structure role? Its use for navigation seems much less important than its use in changing the interaction model for that region.
Comment 23: We suggest that PF consider making breadcrumbs a role. This is a very common feature on websites and it confuses blind users (e.g. user follows links to product description and then encounters breadcrumb trail that starts with "You are here: Home > ...", but "Home" is not the destination he/she had in mind). Of course, this role does not map to an existing accessibility API (at least not in Gnome/ATK, javax.accessibility, IAccessible2, Apple)
There would only be one role for the entire Breadcrumb trail, with no special states or properties. It might look something like this.
<pre>
<p role="breadcrumbs">
You are here:
<a href="../../index.htm">Home></a><a href="../books.htm">Books></a><a href="winnie.htm">Winnie the Pooh</a></p>
</pre>
Would look like this.
You are here: Home>Books>Winnie the Pooh
Comment 24: What is the appropriate role for a control that opens a menu, but is not in a menubar? If it were in a menubar, it appears to be 'menuitem'. But can 'menuitem' exist outside of a menubar or menu? If not, why would the same control have a different role inside a menubar and outside a menubar? Please clarify in the spec.
Comment 25: We suggest considering a splitbutton role.
Comment 26: We’d like to see more documentation of how ARIA roles interact with native HTML roles.
Comment 27: "When the alert dialog is displayed, authors SHOULD set focus to an active element within the alert dialog." Is setting focus to the alert dialog itself an option? This can permit AT to read the entire dialog automatically, which can be less confusing than setting focus to an interactive element, perhaps skipping over the alert message itself. Nesting focusable items can cause some confusion in browsers, however, particular for rtl languages. Either User Agent Implementation or Best Practices discusses expected behavior of the screen reader, so the answer may be implicit in that discussion.
Comment 28: The syntax in the sentence "Assistive technology must treat an article like a document in that article must be processed like an application." looks disjointed. The intent is not clear. This may be an editorial issue, but since the intent is not clear, we can't suggest an alternative wording.
Comment 29: People may think this is a banner ad, not the main title of the page. Perhaps "nameplate" would be a term that better reflects this concept ("masthead" and "flag" are other common terms from the desktop publishing world for this).
Comment 30: The use of 'primary heading' and 'main heading' in the banner role is somewhat confusing. In general, we would have expected that the h1 for a given page would more commonly reside in the "main" landmark role. Suggest revising the definition of the banner role to focus only on site-oriented content (ex. CNN Technology or Yahoo Finance).
Comment 30: We recommend working with HTML5 to incorporate tri-state checkboxes.
Comment 31: Should there be a role for column and row headers that support sorting when clicked? (gridcolumnhdeader/gridrowheader?)
Comment 32: "Many browsers allow users to type in a drop-down select as well." This statement gives the impression that a standard <select> element in HTML allows free text input. Typing in an HTML drop-down list selects an option that start with the character you type but does not generate new strings (in Internet Explorer, Firefox, Opera and SeaMonkey on Windows XP). This statement needs to be seriously qualified.
Comment 33: How do these two roles differ? From the descriptions, we can't tell when it is appropriate to use one or the other.
Comment 34: We have trouble determining when this is the appropriate role, examples notwithstanding. Is the author's name metadata? Why is a footnote metadata? It breaks the linear order, but otherwise seems to be content of the document, not metadata about the document. Are references metadata?
Comment 35: Consider adding support for heading levels.
Comment 36: The description does not say how this relates to the XLink behaviour attributes (see http://www.w3.org/TR/xlink/#link-behaviors). Can the link role only be used for links that load the referenced resource in the same way as traditional HTML hyperlinks (fetch and display instead of the current content, or fetch and display in a new window) or can link traversal also result in embedding? If this role is not intended for embedding on request, what other role would be appropriate?
Comment 37: What is the behavior if a menu contains both menuitemcheckboxes and menuradioitems? is this allowed (current wording seems to allow it). Does this permit only one radio button to be selected, but arbitrarily many checkboxes to be checked, too? If a menu wants to contain 2 different sets of radio items, is there a way to group them so that one may be selected from each set? Is this one of the potential uses of group as a child of menu? That is, does the use of "group" in the second paragraph refer to the role group? Typography doesn't seem to indicate this. And the third paragraph seems to indicate that menuradioitem should be a child of menu. Should role radiogroup be used for this purpose in this context? How does the reference to type separator fit into definitions of discrete groups? Are all items between separators considered part of the same group? (note that this is spelled out explicitly for treeitems - a good model?.)
Comment 38: The description of option indicates it can be associated with a menu, but the description of menu makes no mention of option. How is option different from menuitem?
Comment 39: The definition says "An element whose role is presentational and does not need to be mapped to the accessibility API."
Should a layout table be marked up as a table element with role 'presentation'? Will the content of such a table still be exposed to AT? that is, does the definition mean that the element isn't exposed to AT, or the role isn't mapped to the accessibility API? The longer description of role presentation makes it clearer that the role is not exposed, but the content is (or may be?) exposed. Is the decision about whether content is exposed a function of the element type that has role presentation? If so, can the spec document the expected behavior?
Current discussion on the free-aria list seems to indicate that browsers (at least Firefox) are not interpreting role=presentation this way; they appear to remove all trace of the presentation nodes from being exposed to AT via the API.
The second example in the description of role presentation is confusing. What is the user agent's default behavior for a list item that is being overridden by assigning role=presentation to the li element? Is it the styling as list elements that is overridden? Is it the inclusion of the element in the list's set of items?
Comment 40: Why is this a separate role, and not just a text input with accName=Search?
Comment 41: What’s the relationship between a tab and its tabpanel? How is it made explicit? A markup example would be really useful here.
Comment 42: "A contextual popup that displays a description for an element in a mouse hover or keyboard focused state. Supplement to the normal tooltip processing of the user agent. "
We need a way to activate tooltips from the keyboard, but we think it is a serious mistake to bring them up on focus. The parallel would be if tooltips came up on blur (that is, as soon as the mouse entered that region.) Users need to hover over a control to get a tooltip because there are too many times when that is not the desired behavior and it would be very distracting. Similarly, if a user needs to tab through a series of controls to reach the one she needs, having tooltips pop up on each control as she tabs through will be very distracting, at best, and will likely slow down her ability to reach the desired control. Having it appear automatically may be okay in some cases (ex. additional info on a form input) but for things like links, there ought to be a way for users to ask for it to appear instead of having it appear automatically. We suggest changing "keyboard focused state" to "keyboard activated state".
Comment 42: We'd like to see a mapping from ARIA states and properties to CSS pseudoclasses. Many of these things can be set in multiple ways (aria attributes, html attributes, user actions), and it would be nice for CSS designers to not have to know about those details.
Comment 43: What’s the difference between aria-controls and aria-owns? How would an author decide which to use? Markup examples would be useful here.
Comment 44: Drop-effect means what functional thing happens, right? Not a visual effect like a glow? Please clarify this in the short definition, instead of only in the full description.
Comment 45: We are concerned that authors will generate inconsistent aria-flowto order and tab order. Could the default tab order follow the flowto order?
Comment 46: Why do have the aria-hidden attribute instead of just using css hidden? It allows the possibility of getting the two states out of synch.
Comment 46: For aria-invalid, we suggest revising the second sentence of paragraph 2 to say "User agents MUST inform the user of the error." This would make it more consistent with WCAG 2 SC 3.3.1 and would give an author more confidence in the ability to use and rely on this state.
Comment 47: Does aria-label replace @title? And should it always be styled as display:none?
Comment 48: aria-live. The spec should suggest that AT needing provide users a way to configure what to do with live regions. For example, users should be able to say that all liveregions from doubleclick.com will be treated as polite, regardless of how they are marked up. This capability should be configurable based on URL, among other things. Perhaps this should be addressed in the User Agent Implementors Guide.
Comment 49: aria-multiline. The behavior of pressing the Enter key is inconsistent for textarea controls. (Sometimes it submits the form.) Would aria-multi-line need to be consistent with that behavior? Or is this something that should be changed in browser support for HTML?
Comment 50: What’s the difference between aria-relevant and aria-atomic? How does an author know which to choose? This is explained in the Best Practices guide, but should be addressed in the spec.
Comment 51: "none: Only values from the value list can be selected." - what value list is this? Is this referring to a combobox? What does "none" mean for a simple text box?
Comment 52: "HTML label element, and HTML table cell headers are de facto describedby values." - We think that they are de facto labelledby values, at least for the label element. Why are these considered describedby?
Comment 53: If aria-live is set to "off," what is the expected UA behavior in terms of overriding this setting? An author's use of this property might conflict with WCAG 2.0 4.1.2 (... and notification of changes to these items is available to user agents, including assistive technologies).
Comment 54: We assume that the ids are a list of elements that should be considered children of the current element. Is it an error if more than one elements "owns" another element? Is the element removed from its position implied by the dom hierarchy, and is the user agent responsible for implementing that (lack of) relationship?
Comment 55: How does the aria-relevant property relate to SC 4.1.2? If an author decides that they want to include a live region with scrolling headlines, it sounds like the default (when an author does not specify this state) is to assume that removal of an item does not need to be available to the UA/AT. What mechanisms are in place to help keep users from being confused about things that may have changed since they first read them? To minimize confusion, please consider changing the default behavior to assume that this type of change is relevant.
Comment 56: "This property is marked on the members of a set, not the container element that collects the members of the set." why? Setting this value on every element in the set will be very expensive for large sets, and introduces the possibility of inconsistent values, particularly if the set changes size dynamically. It doesn't seem like the user agent/AT overhead of retrieving the set size from the aria parent element is so onerous.
Comment 57: Definitions for "Keyboard Accessible," "Perceivable" and "Operable" include the language "... indicate required satisfaction of.." (GL 2.1, Principle 2, Principle 1, respectively). Technically, none of these are things you satisfy directly within WCAG 2. Unless the intent was to highlight specific WCAG 2.0 requirements, suggest that the language be generalized (ex. "references in this document relate to...").
Comment 58: Add "Onscreen keyboards" to the bulleted list of examples of AT in the definition of Assistive Technology.
Comment 59: For designers, define "literal" in the definition of "Value"
Comment 60: This section needs to be fleshed out a lot. Rich and Cynthia gave a presentation at ATIA about this and gathered some feedback. They have concrete recommendations to make.