- From: timeless <timeless@gmail.com>
- Date: Tue, 9 Jun 2015 11:34:54 -0400
- To: public-pfwg-comments@w3.org
http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#popuphelp > It may contain, and was designed to handle, interactive elements such as a button, link, or text field. this should generally be written in the plural (buttons, links, and text fields), if you really mean a *single*, then you should use the word "single" or "individual". it's possible that you actually want singular, in which case `handle` is probably the wrong word/phrase, possible "help a user understand" > The key sequence for posting Popup Help was to take advantage of F1's tie to the Help paradigm (F1 calls up application Help for example). This entire paragraph uses `was`, which is odd for a prescriptive document. > Posts the Popup Help widget. `Post` isn't defined here, normally "Open" would be appropriate.. > * One of the following occurs: > * Modal behavior > * Non-Modal behavior This could be rewritten so that an indentation level isn't wasted on `one of the following` > * Moves input focus between elements in the Popup Help's tabbing order. > * Input focus stays in the Popup Help until one of the following occurs: I think you can un-indent this second bullet > Moves input focus to the next tab-able [sic] element in the tabbing order if the following applies: > Tab will move to the next actionable (tabbable*) item in the grid and stay within the grid wrapping at the bottom. please spell `tabbable` consistently > It contains no tab navigable elements in it. Please put the non-modal behavior first, since this is sort of the most important bullet in the entire tree in terms of deciding which way to go -- or you could just stick this into the top level for `non-modal behavior`, as in `non-modal behavior (if the displayed help has no tab navigable elements) > As with other keyboard conventions described here, the Shift+Tab … drop `the` > Shift+Tab has the effect of moving the focus up rather than down and follows the same conventions as described for the modal and non-modal Tab key above. `up` and `down` are really odd. typically `forward` and `backward` `… in the tab order` would be more correct… > Editor's Note > Add link to example. yes http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#radiobutton > If none is selected, focus goes to the first radio button. none => nothing http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#richtext > The user navigates through the toolbar (see toolbar behavior) to a desired attribute and invokes that attribute. see should be a link > When an attribute is invoked, that attribute is applied to the selected text in the editor and focus moves back into the editor at the previous insertion point with the selection intact. it's possible to have no selection (or a collapsed selection), when a user applies an attribute (e.g. underline), that has an effect beyond the "selected text" (of which there is none). > Provide indent and outdent buttons in the menu. what does `outdent` mean here? The author must think there's an obvious relationship between "indenting" and "tab", but sometimes people want \t (0x9) in the middle of a line… > Dojo nightly. > CKEdtor. > YUI Rich Text Editor. normally your examples don't have periods after each line… http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#Site_Navigator_General > A collection of links, buttons, or tabs, usually presented in a region on the left or top of a page, that is persistent across most pages of the site. `left` here discriminates against RTL languages (and pages/sites written in such languages/for readers of such languages). > The container widget implementation should address the following considerations and requirements. I'd expect `:` instead of `.` http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#Site_Navigator_Tree > Unlike the typical static left-hand navigator, a dynamic tree widget could also provide the ability for the user to explore the hierarchy of the site without having to load a parent page in order to see the titles of the children. the children => its children > The tree should implement keyboard navigation consistent with the Tree View design pattern with one exception. I'd expect `:` instead of `.` > See Site Navigator for more details on appropriate labelling of a navigation widget. I just read that section and i can't remember what you're talking about. Please provide an anchor and link to it. > Editor's Note > Add link to example yes note that this one doesn't end in a period (unlike the previous quote for what should be an identical section…) http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#Site_Navigator_Tabbed_Style > aria-multiselectable is true. If aria-multi-selectable [sic] is false, t I think you have a stray `-` here. http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#slider > Right Arrow and Up Arrow increase the value of the slider. RTL?? BTT?? > If the slider is vertical specify aria-orientation="vertical" missing `.` http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#slidertwothumb > Third Tab moves to the next slider thumb or if there are no more, it moves to the next tab stop on the page. Tab *press* > If applicable this is constrained by the value of the other thumb. other thumb => adjacent thumbs http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#spinbutton > For example, select a number from 1 to 59 for the minute of an hour when setting an alarm. 0 is typically a valid minute… > PageUp and PageDown. > Optional: Page Up and Page Down increase or decrease the value in larger steps. please be consistent… > For example, an hour-and-minute spinner would allow only the digits 1-59, zero! http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#tabpanel > The tabs are arranged along one of the edges of the contents but most commonly are found at the top of the page. drop `but` > Left Arrow - with focus on a tab, pressing the left arrow will move focus to the previous tab in the tab list and activate that tab. RTL … "previous" is an LTR thing for Left. > Alt+Delete - When deletion is allowed, with focus anywhere within the tab panel, pressing Alt+Delete will delete the current tab and tab panel from the tabbed interface control. If additional tabs remain in the tabbed interface, focus goes to the next tab in the tab list. An alternative to providing a keystroke to close a tab is to provide a context menu that is associated with the tab title. When focus is on the tab, pressing Shift+F10 or pressing the right mouse button will open a context menu with the close choice > Control+PageUp - When focus is inside of a tab panel, pressing Control+PageUp moves focus to the tab of the previous tab in the tab list and activates that tab. When focus is in the first tab panel in the tab list, pressing Control+PageUp will move focus to the last tab in the tab list and activate that tab. your long "paragraphs" only sometimes end in punctuation… http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#toolbar > A toolbar is a flat non-hierarchical collection of controls that provides quick access to a subset of the functions found in the menubar/menu hierarchy. Rich editors often have toolbars but no menus… > Since navigation between toolbars is accomplished using a Tab keystroke, too few controls within a toolbar also creates a usability issue as it requires numerous Tab keystrokes to navigate between toolbars. the first `between` probably is meant to be an `within`, but this whole thing could/probably should be fixed by encouraging the use of arrow keys instead of tab for navigating within toolbars. http://demos.telerik.com/kendo-ui/editor/index supports using both arrow keys and tab; it also has 13 or so items in its toolbar. Personally, i find navigating through 13 things to get from the page to the editor to be insane. OTOH, demanding that toolbars only have 7 items is also insane. Most editors will have at last as ouch as the Kendo UI i'm pointing to. > it is recommended that they be placed inside a container element with a role of group to allow for keyboard navigation to the entire collection of toolbars. > It is recommended that authors provide a documented key combination that allows a user to move focus quickly to the tool bar from elsewhere within the web application, placing keyboard focus on a tool within the tool bar [sic]. you use both `toolbar` and `tool bar` http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#tooltip http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#treegrid > Left Arrow and Right Arrow keys navigate between columns. If the next cell in the row is empty, focus should not move. consider a tick-tack-toe board as a treegrid: x | | x ----------- o | o | x ----------- o | x | o the description above means that one can't reach from the top left point to the top right point… you might want `first`/`last` as opposed to `empty`… But i'm not really sure. i'm really unsure what you're trying to do -- just because a cell/heading is empty doesn't mean it isn't useful to go to it (e.g. to reach the o below the empty spot, or in otherwise sparse grids…) > If the cell contains an editable field, the Enter key starts edit mode and the Escape key exits edit mode. i'd expect `edit mode` to be capitalized or italicized or something… > Shift+F8 Allows additional cells to be added to a previous selection to accomplish non-contiguous selection. can i remove a cell from the selection? (toggle?) > To make a treegrid read-only, set aria-readonly="true" on the document element having a role="treegrid." the period is on the wrong side of things. i'm not going to flag all instances… > To make a treegrid read-only, set aria-readonly="true" on the document element having a role="treegrid." This will make all gridcells read-only. isn't the second sentence redundant? http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#treeview > node > An item in a tree. stray `.` > parent node > Node with children. It can be opened / expanded or closed / collapsed the `.` here should probably be a `;` or something > open node > Expanded node with children; first-level children are visible. or something -- this whole section is inconsistent > end node > Node with no children > Arrowing to an item with the keyboard or clicking on an item with the mouse will focus and select the node. Any previous selections are cleared missing `.` > Up Arrow and Down arrow keys move between visible nodes. the second `Arrow` should be uppercase too… > Left arrow key on an expanded node closes the node. or the first one shouldn't be, whatever… > Typing a letter key moves focus to the next instance of a visible node whose title begins with that letter. typeahead? > *(asterisk) on keypad expands all nodes. plus [expand]? minus [collapse]? http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#windowsplitter > Enter - If pane controlled by the splitter is not collapsed, then collapse the pane. If the pane is collapsed then restore the splitter to its previous position. you sometimes include a `-`, but only sometimes > End Optionally moves splitter so the associated pane is the largest allowed size. > Home Optionally moves splitter so the associated pane is the smallest allowed size. In many cases this will collapse the pane completely. i'm totally unfamiliar w/ this behavior, i'm not sure it matches any logic i've seen. also, it doesn't work on my mac (ff38.0.5/osx10.6.8) http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/layout/test_BorderContainer.html http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#wizard > A Wizard can be done in several ways. Either is valid. the second sentence here is both odd and useless, please drop it. (minimally: either is => all are) > Escape cancels the wizard. > Escape cancel, exit without saving you're missing an `s`
Received on Tuesday, 9 June 2015 15:35:22 UTC