- From: <Anna.Zhuang@nokia.com>
- Date: Fri, 16 Jan 2009 12:40:04 +0200
- To: <shawn@w3.org>, <w3c-wai-eo@w3.org>
Hello Shawn, I am planning to participate in today's call but nevertheless my comments in electronic form. It is hard to review 3 big documents in a realtively short period of time so I do my best by skimming thru the docs. Also it would be good if you e.g. allocate the next week's telco for the same subject or if that is not necessary allow more time for feedback and comments via e-mail. ARIA Overview page does not contain WAI-ARIA User Agent Implementation guideline. Generally on ARIA and WAI pages, I still don't see relationship between WCAG and ARIA in any place. IMO ARIA is no less important that WCAG. UAAG work hand in hand with WCAG and now WAI-ARIA User Agent Implementation guideline has been drafted. So this overall picture needs to be updated. WAI-ARIA 1.0 ============ Abstract references ARIA Overview page. Should it instead give the link directly to ARIA suite with or without mentioning ARIA Overview? ARIA Overview is not meant for any specific audience and reader of the overview may or may not read ARIA spec. But once you are in ARIA spec, sure enough you are going to read spec's introduction that provides information similar to ARIA Overview page. Introduction has a sentence: "Assistive technology software can transform the presentation into a format more suitable to the user, and can allow the user to interact in different ways than the author designed." Good to have some example here of what suitable format may be and what would be different ways of interaction. It is good to start Introduction with one paragraph of the general problem statement (borrow something from ARIA Overview). Othrwise Introduction jumps to what ARIA is offering without explaining what are the problems that ARIA is addressing. 1.2 Use cases. One would expect a bullet list of use cases here. The current material presentation hardly looks like use cases, is not sistemised and not labelled in any way. 3. I would change the title to ARIA Requirements. The current title looks a bit odd from the table of content. Also each chapter is anyway labelled as normative or informative. Can anything be done with the diagram in 4.4? If you print the whole doc the diagram is unreadable. Even id diagram is scaled and printed to A4 it is rather hard to concentrate on a very small font. Place boxes closer and make them bigger? Stretch diagram vertically so that it does not require so much horizontal scrolling? Should definition of roles be moved to appendix and be labelled as normative? No intro text between 5 and 5.1? States and roles are colour coded. I don't see the legend explaining what is marked as yellow, grey or blue? Also is colourcoding absolutely necessary? My experience is that it is always good to have as black&white specification as possible. Most people use BW printers to print large docs. WAI-ARIA 1.0 User Agent Implementation Guide ============================================ Not all links in the table of content work. Some jomp to the top of the spec. The abstract is too short and this document it NOT YET part of ARIA suite as described in ARIA Overview and noted by me earlier in this mail. Introduction does not describe relations of this doc to ARIA spec. generally the top of introduction lacks some general text stating the problem this document is addressing. Also it is important to state that the basics are explained in ARIA and reader of this document is supposed to be familiar with ARIA spec. It would be good also to give a status of this document. It does not seem to be a normative document. Perhaps can say that this is supporting document to ARIA spec and the target audience dor this doc is user agent developers. In the introduction it is good to have some reference to where these APIs can be found ATK/AT-SPI on Linux MSAA/IAccessible2 on Windows At least MSAA has a reference link just before 4.3. need to have it in the intro. Again colour coding does not have any legend. Last paragraph before 2.2. What is Gecko document? It is neither linked nor explained. 2.2 bullet 5. This is the first time AT occurs but the acronym is not explained. 2.3 title, replace AT with Assistive technology 3. Mapping ARIA to APIs. Accessibility APIs? If so, it needs to be stated in the title. This is important. Why managed stated deserve a separate paragraph and do not come under the paragraph 3? Chapter 4 has no intro whatsoever. Oddly enough the title is "managed states" but this chapter has zero occurrence of this term. Is the title correct? WAI-ARIA Best Practices ======================= Unlike two other docs this one has a good abstract. This is probably a credit to Lisa P. My only comment is, what is a best practice? "This document specified best Practices..." Best Practices is a title and there is a meaning to it. I would replace the first sentence of the Abstract with the first sentence from the Introduction (with slight modification)--> "The WAI-ARIA Best Practices guide provides readers with an understanding of how to use WAI-ARIA to create an accessible Rich Internet Application." Also the word "provide" is used too frequently. Chapter 2 mentions "existing ARIA-enabled widget library". I wonder if such libraries exist publicly? I would remove the word "existing" alltogether. The message will not suffer any loss. Again colour coding has no legend. Unify the titles, either providing/setting/allowing across the doc or provide/set/allow. Now it is a mix. In chapter 9 what does it mean "Placeholder for Local Index"? Typo in the first sentence of chapter 10. In chapter 10 I would remove two sentences that have recommendations to reuse existing libraries. Firstly it is a matter of ones choice to reuse someone's work or not. Secondly, being true to the spirit of public standards, some existing implementations should not be promoted by the standards. I would write chapter 10 in the following way: Writing rich internet applications is much more difficult than writing in HTML. It requires extra effort to ensure your application runs in multiple browsers and supports WAI-ARIA. Authors of rich internet application widget libraries will have to go through: * extensive testing with assistive technologies * cross browser testing * testing to ensure that the widgets respond to desktop settings * testing to ensure that the widgets match a common keyboard style guide There are publicly available UI component libraries which have already implemented WAI-ARIA, e.g. Dojo Toolkit Dijit library. (Any other? Who can guarantee quality assurance of Dojo Tookit to comfortably reference it in W3C standard???) Reusing such libraries is one way to start developing accessible rich internet applications. That's all I've got after scrolling 3 docs. Regards, Anna >-----Original Message----- >From: w3c-wai-eo-request@w3.org >[mailto:w3c-wai-eo-request@w3.org] On Behalf Of ext Shawn Henry >Sent: Thursday, January 15, 2009 12:13 AM >To: EOWG (E-mail) >Subject: EOWG: Preparation for Friday 16 January 2009 teleconference > > >EOWG, > >The agenda for the 16 January 2009 teleconference is updated >at: http://www.w3.org/WAI/EO/#agenda > >Please take some time before the teleconference to review the >in-progress WAI-ARIA documents. Be prepared to comment on them >from an education and outreach perspective (not the technical >content), such as the introductions and overall flow. > >The editors would also like some feedback on: >a. Is the overall progression from top to bottom logical and >understandable? >b. As you read through them, do you feel you need some >background to understand it that is missing? > >Regards, >~Shawn > >----- >Shawn Lawton Henry >W3C Web Accessibility Initiative (WAI) >e-mail: shawn@w3.org >phone: +1.617.395.7664 >about: http://www.w3.org/People/Shawn/ > >
Received on Friday, 16 January 2009 10:41:29 UTC