Fwd: a11y & i18n of Web Notifications / was: Web Notifications I18N Review: [I18N-ISSUE-161, I18N-ISSUE-162]

Copying www-international@.


Begin forwarded message:

> From: Artur Ortega <Artur@ortegalink.com>
> Date: June 30, 2012 16:24:56 PDT
> To: public-web-notification@w3.org, w3@norbertlindenberg.com
> Subject: a11y & i18n of Web Notifications / was: Web Notifications I18N Review: [I18N-ISSUE-161, I18N-ISSUE-162]
> 
> Accessibility of Web Notifications
> 
> Modern web browsers and mobile devices support built-in accessibility.
> Good examples are VoiceOver on iphone/ipad, AppleTV or Macs. Google's
> Chrome provides the ChromeVox screen reader.
> Screen readers make content of web browsers perceivable,
> understandable and operable for blind and visual users as long the
> content follows the W3C's Web Content Accessibility Guidelines 2.0
> (WCAG 2.0).
> 
> Screen readers read the web content in the programmatically defined
> language to make content perceivable and understandable to blind and
> visual impaired users . Any non-textual content has to provide a
> textual alternative to make the information readable and therefore
> perceivable for blind and visual impaired users. For making sure web
> content is operable for screen reader users it's important the
> interaction is provided in a device independent way.
> 
> Web Notifications must meet the WCAG 2.0 Guidelines to grant
> equivalent access of these notifications to disabled users. Some of
> the WCAG 2.0 guidelines are overlapping with i18n because screen
> readers are able to read text in a huge variety of languages and local
> accents and can switch between these instantly depending on language
> definitions. If no or a wrong language is provided the content could
> be read in the wrong language or accent which could make the read
> content impossible to understand.
> 
> Because the content in Web Notifications don't rely on web content
> (e.g. HTML), the specification has to be reviewed against WCAG 2.0
> itself:
> "In particular, notifications as specified here only can contain text
> and icon content. In the future, notifications generated from web
> content may wish to contain web content themselves, but that is
> outside the scope of this document."
> 
> *  title:
> The title is textual content. For making sure the title of the Web
> Notification is read correctly by the screen reader it has to provide
> additionally the used language.
> Not having any meta information about the language of the "title" is
> conflicting with WCAG2.0 Guideline 3.1 Readable: "Make text content
> readable and understandable." - especially 3.1.2
> 
> Here some further explanation of the importance to provide language
> information for the title:
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-other-lang-id.html
> Proposed fix: an title-lang element analog to title-dir.
> 
> * title direction:
> Meta information wich is important to display and to read the title in
> an understandable way.
> 
> * origin:
> Predefined meta information which will be only read programmatically
> and won't have an obvious impact on accessibility.
> 
> * body:
> The body has identical requirements as thte title of a Web
> Notification: The body is textual content. For making sure the body of
> the Web Notification is read correctly by the screen reader it has to
> provide additionally the used language.
> Not having any meta information about the language for the "body" is
> conflicting with WCAG2.0 Guideline 3.1 Readable: "Make text content
> readable and understandable." - especially 3.1.2
> Here some further explanation of the importance to provide language
> information for the body:
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/meaning-other-lang-id.html
> Proposed fix: an body-lang element analog to body-dir.
> 
> * body direction
> Identical to title direction: Meta information wich is important to
> display and to read the body in an understandable way.
> 
> *  tag:
> The tag member is only used for programmatically dealing with multiple
> instances of the messages.
> 
> * icon:
> An icon can provide important information (importance or
> confidentiality of mail) which wouldn't be available for blind or
> visual impaired users without textual alternatives. An icon needs an
> ALT text and the used language of the alternate text. This means the
> Web Notification conflicts with Guidelines 1.1 and 3.1.2 .
> WCAG 2.0 Guideline 1.1 "Provide text alternatives for any non-text
> content so that it can be changed into other forms people need, such
> as large print, braille, speech, symbols or simpler language."
> Further information can be found at:
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/text-equiv.html
> Proposed fix: an icon-alt and icon-lang element
> 
> * URL
> Is only a programmatical way to access data of the icon and has no
> obvious implication on accessibility of Web Notifications.
> 
>  The Web Notification document mentions additionally that the
> notification " object offers a click event".  A click event is not a
> device independent event. Blind screen reader users usually don't use
> a mouse and won't "click" any object. They probably will try to fire
> an event with the keyboard or with a touch event on a touch screen
> device.
> This description conflicts with WCAG 2.0 Guideline 2.1. Some further
> explanation can be found at
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation.html
> 
> It would be  additionally important to provide  implementation
> guidelines to ensure accessibility. There are several areas not
> covered by this document wich would be essential for users with
> disabilities, e.g. WCAG2.0 Guidelines 1.2, 1.3, 1.4, 2.2, 2.3 & 2.4.
> 
> Artur Ortega

Received on Tuesday, 3 July 2012 17:10:33 UTC