Re: Deadline: WAI-ARIA FAQ

> Shawn, ...shall I rewrite with the ARIA/vendor neutral = no hacks/less 
> costly?

um... I dunno. At this point (wanting to wrap this up), if it's not a significant issue, I'd say just leave it as is for now... but  I'll leave it to Lisa to say if it's a significant issue and should be mentioned. :)

>> Sorry, I've been meeting ALL day...literally...and have to race out in 
>> 5 minutes....but....

And I didn't get access at all yesterday while traveling, though I expected to be able to. :(

Some questions/comments from as much of a review as I can squeeze in right now:

* Many answers are much simpler, shorter, and direct in this edit. Great job, Sharron!

* in "2. What is WAI-ARIA intended to do?
WAI-ARIA increases the accessibility of Web objects - often referred to as "widgets" - that are developed with AJAX, DHTML, and other technologies. Web widgets are portable pieces of executable code, in DHTML, JavaScript, and such, that are generally recognized user interface controls. WAI-ARIA defines roles for widgets and describes the states and properties that characterize them. This semantic information about these Web-based widgets is then available to assistive technologies, in the same way it is for traditional desktop applications.
":
- I'm afraid "WAI-ARIA defines roles for widgets and describes the states and properties that characterize them." Will scare off some of our target audience for this FAQ. Perhaps adding a simple example would help? Lisa - can you provide this?
- This still seems too focused only on widgets. What about the "new navigation techniques to mark common Web structures as menus, primary content, secondary content, banner information and other types of Web structures."? I feel that is still missing from this answer. Perhaps a short (one-sentence even) paragraph should be added to cover this aspect?
- Change "AJAX" to "Ajax" (pre previous decisions in EOWG, it is more commonly used as a "word" word than an acronym, including by it's creator <http://www.adaptivepath.com/ideas/essays/archives/000385.php>)
- Low priority: Do you want to tighten this up so it's not repeating the technologies? "...that are developed with AJAX, DHTML, and other technologies. Web widgets are portable pieces of executable code, in DHTML, JavaScript, and such,..."

* under "5. What are common accessibility barriers with widgets?"
- typo in "Dynamic Web content, such as that rendered by widgets, may in inaccessible to people using assistive technologies."

* In "4. To what types of widgets does WAI-ARIA apply?":
- typo in: "WAI-ARIA techniques apply to widgets such as buttons, drop-down lists, calendar functions, tree controls (for example, expandable menus ), and others."

* "5. What are common accessibility barriers with widgets?"
- I continue to be uncomfortable with the heavy focus on widgets throughout this FAQ, and I'm not sure if that's my misunderstanding of the scope of ARIA or an issue with the FAQ. For example, the answer to this question and WAI-ARIA itself addresses more than widgets, such as changing content that can happen *without* any widgets, afaik. So I don't understand why you have widgets in this question, as opposed to something more broad like "What are common accessibility barriers that WAI-ARIA addresses?" or "What are common accessibility barriers that can be solved with WAI-ARIA?"
- Secondly, I'd like to take another look at this questions and answer fits with the Overview, but will need to take more time on it than I have right now...

* In "6. What does WAI-ARIA offer to improve Web accessibility?":
- In "properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates; critical updates may be presented in an alert dialog, while incidental updates may stream in a marquee control." I think you need to clarify what is any example. Also, I personally shuddered at "marquee control" partially because on potential accessibility issues. Is there another example or can we just leave it off? How about: "properties to define live regions of a page that are likely to get updates (such as stock quotes), as well as an interruption policy for those updates (for example, critical updates are presented in an alert dialog box and incidental updates are provided within the page)"
- "a way to provide keyboard navigation for the web objects and events described above." limits it to those mentioned above. Instead, I think those are only examples. How about: "a way to provide keyboard navigation for web objects and events, such as those mentioned above."
- Need to be consistent in punctuation on these. I think none should have a period, but I leave for you to choose. However, do need to fix: roles to describe the type of widget presented, such as "menu", "treeitem", "slider" and "progressmeter."
- (Personally I think these would be easier to read if they started with capital letters, but I don't feel strongly on this and we don't have any strong style guidelines on this.)
- In "roles to describe the structure of the web page, such as headings, regions, and tree grids." is 'tree grids" the same as 'tree controls'? If so, is there any reason not to use 'tree controls', which is the term used previously (ans also the one at least I am more familiar with).

* In "7. What happens in current and older browsers when WAI-ARIA is implemented?"
- typo & suggest adding "Web" to "page" just to clarify: "WAI-ARIA coding methods have no affect on how a page renders in older browsers ."
- W3C style guide has Web always capitalized. (Though I personally don't agree with that, I've not felt it worth the time to address it, and so just do it. :)

* In "8. Does WAI-ARIA significantly increase the amount of widget code?"
- Why did you leave "widget" in the question text?
- Generally, I like that you have simplified the answer. However, I still don't think it adequately addresses my previous issue: "[perhaps this answer is for browsers and AT, not Web sites? if so, need to clarify (and probably more down since that is a smaller audience)]"
- I think you can further simplify it by deleting "- descriptions that provide information to assistive technologies -" from the first sentence, since this is pretty clear from the answers above.

* For "10. Are there JavaScript toolkits that provide built-in WAI-ARIA support?
Yes, some exist, and the number is growing. JavaScript toolkits that integrate ARIA techniques are making the technology increasingly practical for individual authors, who will be able to meet project accessibility requirements using keyboard and assistive technology support that is built-in.
"
- Can you just say "Yes, some JavaScript toolkits already have WAI-ARIA support built-in, and others are adding it." and leave off the rest of the text? - especially since the next question addresses it.

* In "11. How can web developers implement WAI-ARIA?"
- I think you want to change the colon to a period in "Include WAI-ARIA techniques in your custom widgets: When developing custom..."
- Since we're publishing this along with the new WAI-ARIA docs, I think change "WAI will make documentation and examples available in early 2008." to "Documentation and examples are provided in the [@@Primer??@@Best Practices]."

* Need to update the answer to "12. As a Web developer, what should I do with WAI-ARIA now?" since the documents will be available when the FAQ is published.

* Misc typos
- There are several places where there are extra spaces before periods and parenthesis. Sharron, could you do an edit pass through the document for those. (Some are noted above, but part way through I quit listing each of them.)
- I think we need to use "WAI-ARIA" on first reference in each question and answer. See http://www.w3.org/WAI/EO/changelogs/cl-aria-docs#terminology

* Let's talk about "FAQ's" versus "FAQ"...

All for now...

~Shawn

Received on Wednesday, 30 January 2008 18:06:45 UTC