Spelling feedback for FPWD: WAI-ARIA Authoring Practices 1.1

http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/

Hi. I'm sending a first round of comments today. I won't have time to
actually read your document (and send comments) today.

> Where it is helpful to do so, the examples refer to detailed explainations [sic] of supporting concepts in subsequent sections.

explanations

> The sections that follow the examples first provide background that helps build understanding of how WAI-ARIA works and how it fits into the larger web technoloby [sic] picture.

technology

> The accordion panel uses the role tabpanel and should have an aria-labelledby relationship referencing the correponding [sic] header having a role of tab

corresponding

> A button is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, cancelling* an action, or performing a delete operation.

en-us: canceling

> As a general rule the actual calendar portion of the date picker follows a table structure where days of the week and calendar day numbers are layed [sic] out in table cells.

laid

> When the datepicker is active a calender [sic] day of the week always has focus.

calendar

>    This dialog box is dragable [sic] by the mouse user and an equivalent behavior (Drag & Drop) should be offered to the keyboard only user.

draggable (Google: dragable "Did you mean: draggable"; ratio is >5:1)

> If a WAI-ARIA grid is not overlayed [sic] on a table, authors should mark the rowheader, columnheader, and gridcell roles on the appropriate elements.

overlaid

> The Tab behaviour* below differs from some native browser behaviors where Shift+Tab sometimes moves to the last button in the group, if none are selected.
>     The edit control is provided by the browser; it provides the keyboard support for navigating, adding, removing and selecting text, so that behavior is not defined by the rich internet application.

w3c is en-us, please use "behavior" consistently

>    CKEdtor [sic]

CKEditor ??

> The site navigator patterns described in this guide are for interactive navigation widgets designed to help standardize solutions to accessibility requirements that have often either been ignored or implemented with other methods that are more limitted [sic] in their usefulness.

limited

>        Focus management: When the widget receives focus, the item in the widget that is currently active (e.g., currently displayed) should recieve [sic] the focus.

receive

> If the navigator visually communicates which page is currently displayed, the navigation item must be able to programatically [sic] communicate the currently displayed status using aria-selected, aria-checked, or aria-pressed.

programmatically


> When they move into a new context, some of the labeling from elements containing the new focus or reading location may be rendered by the assistive technology, to give context to the details to be read next.
> See Site Navigator for more details on appropriate labelling [sic] of a navigation widget.

labeling (please use consistently)

> When focus is in the last tab panel in the tab list, pressing Control+PageUpwill [sic] move focus to the first tab in the tab list and activate that tab.

Please insert a space before `will`

>Visually, disabled buttons are grayed-out, and typicially [sic] not placed in the navigation order.

typically

>    Toolbar that does not require mananged [sic] focus

managed

> This can be determined by using the [dom] * tree structure created by the browser when parsing the host language. By using the parent child relationship of the DOM*, an assistive technology can determine all the related toolbar widgets associated with the toolbar.

Please consistently use "DOM" instead of "dom"

As someone who is running a spell checker on your document, could you
please consider changing: `button` in the following src= attributes to
`button-`:
       <img src="buttoncut" role="button" id="button1" alt="cut">
       <img src="buttoncopy" role="button" id="button2" alt="copy">
       <img src="buttonpaste" role="button" id="button3" alt="paste">

The fewer tokens you have in your document that aren't in a
dictionary, the easier it will be for someone to run your document
through a spell checker.

>        // the same colour *, or there is no legitimate url to the background image.
> Always draw the focus for tabindex="-1" items and elements that receive focus programmatically when supporting versions of Internet Explorer older than 8 - Choose between changing the background color via something like this.style.backgroundColor = "gray"; or add a dotted border via this.style.border = "1px dotted invert".

en-us: color

> In the case of a muti-selection [sic] list box a developer may gray selected items as they move focus to list box items to toggle their selected state.

multi-selection

>    <div role="applicaton" aria-labelledby="calendar" aria-describedby="info">
data-sic-attributes='role="applicaton[sic]"'

! application

> It is prefereable [sic] to have the descriptive text in prose as well so that it is readily available to all users.

preferable

 <dt id="anathema">anthema</dt>

anathema ...

> For example, you could have a dialog box erected from HTML <div> and you need to assocate [sic] a label for the dialog.

> In some situations, a child is reused by multiple parents or a child is separated from its sibilings [sic] or parent in the DOM tree.

siblings

> The presentation role overrides the element's native implicit role, and informs the user agent to not publish the element to the accessiblity [sic] API.

accessibility

> The section needs to be reordered, so that instructions on how to use the math role properly appear before considerations of legacy content and negative examples (such as the use of generic HTML to approximate a visual representation of a mathmatical [sic] expression).

mathematical

WAI-ARIA brings advanced accessibility features of the desktop to the
web through the creation of cross-cutting technologies that (X)HTML
authors can incorporate in their markup. WAI-ARIA defines roles,
states, and properties, where those roles reflect standard GUI
elements that are recognized by accessility [sic] Application
Programming Interfaces (APIs).

accessibility

> Accessibility information surfaced to assitive [sic] technologies is provided only by the HTML element's tag name, with only the accessibility attributes that tag can provide.

assistive

> Accessibility infomation [sic] mapped to a DOM element in the Document Object Model

information

> DHTML example of GUI-like notebook tab with a data drid [sic]

grid?

> Editor's Note: Figure 7, described as WAI-ARIA tree widget usability comparision, [sic] refers to a resource that has not yet been found.

comparison

Received on Friday, 5 June 2015 20:51:01 UTC