Comment 1: We suggest including an example to cover the use case where an author may not want to include the long description on the same page. (ex. a complex chart where a describedby attribute points to an id on the page which contains a link to a second resource containing the complete description).
Comment 2: There are a number of problems with the Step 2 example:
Comment 3: Steps 3-5: Please add alt attributes to the img elements in the example code.
Comment 4: Step 9: "It also ensures that visual focus is indicated when the element receives focus." - We don't understand how this follows from setting the alt attribute.
Comment 5: See Comment 42 on the WAI-ARIA spec on this topic. We believe that automatically bringing up tooltips on focus is often bad design that will create an unpleasant experience for keyboard users. A keyboard command should request that the tooltip be displayed. (It would also be possible to introduce a delay before bringing up the tooltip, as happens with hover, but this makes perhaps unwarranted assumptions about the manual dexterity of the keyboard user.)
Comment 6: It is clear that the element with attribute presentation is removed from the accessibility hierarchy. However, this section implies, for a table, that the table substructure elements will also be removed. How does an author or user agent implementor know which additional subelements elements are also covered by a presentation attribute? If a ul or ol element is given role presentation, are its children li elements also removed? Or are all descendent elements removed (but not their contents)? What if a layout table contains important structural markup within its table cells? The spec needs to be clearer about the meaning of role presentation.
Comment 7: The first example in the discussion of the group role is a row in a grid. Does this imply that group could/should be used instead of row within a grid? Are group and row equivalent roles within grids?
Comment 8: "Gridcells are focusable within a grid unlike a table." Does this mean that the author is (always) responsible for making them focusable, via tabindex or aria-activedescendant? or can the author assume that the user agent will make them focusable? We have similar questions about expanding and collapsing rows.
Comment 9: aria-relevant='text' "Textual content includes text equivalents, such as the alt attribute of images." This seems different from the interpretation given for role=presentation, where alt attributes of images are not considered text content (hence not exposed). Please be consistent about whether alt text is considered the text of an element or not.
Comment 9: Item 3: How can it be determined that all source objects have been grabbed? By nature of the functionality, the user is free to keep adding or removing source objects. It seems like it would be necessary to set the aria-dropeffect attributes every time the source objects change.
Comment 10: The choice of Ctrl as the modifier key for Global recommendations is the intuitive modifier on Windows and Linux, but it would not be intuitive on the Mac. We think the modifier should be consistent with the OS conventions
Comment 11: "the author must provide documentation of those key mappings in the contents of the web page." While we understand the motivation for this clause, this is too restrictive. For a web application, it may make much more sense to provide separate training and documentation than to include documentation of keyboard commands directly in the page.
Comment 12: "Using col and rowspan should be reflected in the keyboard navigation." We assume this is colspan and rowspan? Since there are no ARIA properties for these attributes, they could only be used if the grid is based on HTML table mark-up. Consider providing corresponding ARIA grid properties.
Comment 13: "If a widget is in the current grid cell that also uses and ESC key, then the keys will bubble up to allow each ESC to be used." Does this mean that it is not possible to execute the ESC action on the widget without also leaving Actionable Mode? This needs additional clarification.
Comment 13: "Spacebar is a toggle selected/unselected." What does it mean to unselect a radio button? Does this return the radio group to its initial state, with nothing selected? Since this is non-standard behavior, it should be spelled out more clearly.
Comment 14: Regarding Ctrl+PageUp/Ctrl+PageDown. This is a serious usability issue. We think we should not reuse those keystokes, even though they are standard.
Comment 15: Since Arrow is not a modifier key, Ctrl-Arrow-Space makes no sense. What key combination was intended here?
Comment 16: "The trigger element to which the tooltip is attached, e.g., a link, should never actually lose input focus." This means that any trigger element with a tooltip must implement the tooltip keyboard behavior. e.g. ESC, onblur etc. This seems problematic. At the very least, it leads to extensive code duplication.
Comment 17: "If more then one widget uses the same keys, e.g., Esc, then they should be handled in a Last In First Out (LIFO) manner." - Please clarify; this makes it sound as if you cannot get the ESC behavior of any widget without getting the ESC behavior of all.
Comment 18: Localizing the hot key used seems like a bad idea. Localized names may not start with unique letters, and predictability of keyboard access goes down as each author decides how to localize the commands.
Comment 19: Arrow commands should not depend on the orientation of the splitter, since blind users have no way to find out what that orientation is. Always make Left Arrow and Up Arrow move splitter left or up, as appropriate.
Comment 20: Why is F6 is listed here, unless it is supposed to take focus from the splitter to an adjacent pane? Once focus is on the pane, the splitter can't control whether it rotates through other panes.