- From: Marcos Caceres <marcosscaceres@gmail.com>
- Date: Tue, 5 Aug 2008 11:17:42 +1000
- To: "Steven Faulkner" <faulkner.steve@gmail.com>, "Arthur Barstow" <art.barstow@nokia.com>, "Sally Cain" <sally.cain@rnib.org.uk>, "Cynthia Shelly" <cyns@exchange.microsoft.com>, wai-xtech@w3.org, public-webapps <public-webapps@w3.org>
Hi Steve, Cynthia, and Sally, On Tue, Aug 5, 2008 at 12:54 AM, Steven Faulkner <faulkner.steve@gmail.com> wrote: > Hi Marcos and Arthur, thanks for taking the comments into account. No probs. Thanks for taking the time to provide them. > can I suggest the last part: > "The user interface language MUST also be accessible to screen > readers, allowing relevant sections of text and functionality to be > accessed by non-visual means." > > be replaced with something like: > > "The name, role and state of all interface elements MUST be available > to assistive technologies such as screen readers, to allow relevant > sections of text and functionality to be accessed" Ok. Done. > > and the rationale be modified: > > from > "screen readers and similar assistive technologies" > > to > "screen readers and other assistive technologies" Ok, below is the final text which hopefully addresses everyone's comments. To assist me with the Last Call Disposition of Comments, could you please acknowledge if you are satisfied (or not) with what is now in the spec: -- R37. Language Accessibility A conforming specification MUST specify that the language used to declare the user interface of a widget be either HTML or a language that is accessible at the various levels specified by the WCAG 2.0 (perceivable, operable, understandable, and robust): specifically, the langauge MUST provide keyboard access to interactive graphical elements, and provide means to access the widget's functionality through a non-graphical UI. For the user interface language, the role and state of all interface elements MUST be available to assistive technologies such as screen readers, to allow relevant sections of text and functionality to be accessed. Motivation: Compatibility with other standards, current development practice or industry best-practices, ease of use, accessibility. Rationale: To recommend a language, or a set of languages, that will allow authors to realize their designs, while at the same time remaining accessible to screen readers and other assistive technologies. -- Thank you all again for taking the time to comment and improve this requirement. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Received on Tuesday, 5 August 2008 01:24:45 UTC