W3C home > Mailing lists > Public > public-web-notification@w3.org > July 2012

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

From: Artur Ortega <Artur@ortegalink.com>
Date: Sun, 1 Jul 2012 00:24:56 +0100
Message-ID: <CABouHGTzXcncb4Rx9tkaBDiApxS=VshoeaswoWeM_ht-=7R-ew@mail.gmail.com>
To: public-web-notification@w3.org, w3@norbertlindenberg.com
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 Sunday, 1 July 2012 20:57:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 December 2012 14:48:28 GMT