Re: Spelling feedback for FPWD: WAI-ARIA Authoring Practices 1.1

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

> This document provides readers with an understanding of how to use WAI-ARIA 1.1 [WAI-ARIA] to create accessible rich internet applications.
> Is it clear how to create accessible Rich Internet Applications?

You use both "Rich Internet Applications" and "rich internet
applications", I'd encourage you to only use one casing, offhand, I
favor the capitalized form.

> As explained in Background on WAI-ARIA, languages used to create rich and dynamic web sites, e.g., HTML, Javascript, [sic] CSS, and SVG, …
> Next, the guide covers general steps for building an accessible widget using WAI-ARIA, JavaScript, and CSS, including detailed guidance on how to make rich internet applications keyboard accessible.

JavaScript is a proper noun and should always be spelled as such

> This section has not been updated since it was integrated from APG version 1.0 -- an APG taskforce review is pending.

APG is never introduced, and while it is remotely possible to figure
out that it's Authoring Practices Guide, it's not particularly easy.
Please ensure that the first introduction of Authoring Practices Guide
includes [APG] if you're going to use APG at all, and really, `APG
version 1.0` should be a link to some document. Either `APG taskforce`
should be a link to something, or `APG taskforce review` should be a
link to a bug tracker something.

> By adopting WAI-ARIA, both developers of static web sites and of dynamic Internet applications can improve the usability, accessibility, and scalability of their products.

probably "Internet Applications" …

> Developers of static web content can continue to follow the 1999 WCAG 1.0 standards, while improving usability and accessibility through the use of WAI-ARIA landmark roles, aria-labelledby relationships, and properties like aria-invalid and aria-required that can apply to HTML form controls.

could `1999 WCAG 1.0 standards` be a link to something?

> to achieve accessibility, they need to use WCAG 2.0.

Shouldn't [WCAG20] be in your References? If not, could you at least
make this a link? (similarly for [WCAG10])

btw, it'd be helpful if you had links on your anchors so i didn't have
to go to the toc to get the section i was looking at…

http://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20150514/#accordion
> Left arrow
>    When focus is on the accordion header, a press of up/left arrow keys moves focus to the previous logical accordion header.
>    When focus reaches the first header, further up/left arrow key presses optionally wrap to the first header.

first => last ??

> Control+Up arrow - Moves focus from anywhere in the accordion content to its associated accordion header or tab respectively.

There's no Control+Down arrow. If it doesn't do something, please say
so. It's confusing to read a list of up/down's and see one missing.


> Control+PageUp -
    When focus is inside of an accordion pane, pressing Control+PageUp
moves focus to the accordion header of the previous accordion pane.

> Control+PageDown -
>    When focus is inside of an accordion pane, pressing Control+PageDown moves focus to the header of the accordion pane.

of the => of the next ??

> In the case of an accordion, focus simply moves to the header and requires Enter/Space to expand/collapse the accordion pane.

This is in the Accordion section, the first 6 words make no sense in
context. -> drop (or recopy the text from Control+PageUp)


> End - When focus is on the accordion header, an End key press moves focus to the last accordion header.
> Home - When focus is on the accordion header, a Home key press moves focus to the first accordion header.

the according header => an accordion header ??

>     When deletion is allowed, with focus anywhere within the tab panel or tab, 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.
> If no additional tabs remain, then focus moves to the last place that held focus in the previous tab panel.


.______.
|-A -- |
|-B -- |
|-C --*|
|  cook|
|-D -- |
|______|

Focus is on C, I press Alt+Delete, C is killed, focus shifts to
"next", i.e. D. I press Alt+Delete, D is killed. You presumably want
to focus B, but the text doesn't properly say that, "B" is not "next"
from "D".

> An alternative to providing a keystroke to close a tab is to provide a context menu that is associated with the tab title.

This text is a non sequitur, the context is deleting tabs not closing them.

> The accordion component must have a role of tablist and have aria-multiselectable="true" This will enable an assistive technology,

You're probably missing a period before "This"

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

You're missing a period at the end of the bullet

> An accordion should manage the selected state of each tab by maintaining its aria-selected state.

aria-selected isn't a link (it is elsewhere in similar contexts)

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

It might be worth noting a convention for deleting a completion
suggestion (shift+del)

Received on Friday, 5 June 2015 21:48:36 UTC