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

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

From: Artur Ortega <Artur@ortegalink.com>
Date: Wed, 4 Jul 2012 22:12:54 +0100
Message-ID: <CABouHGS0R0tmgadmmJHq1u+ZFZjwG3Jo06FfJ+n8vR_24Wz-sg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: public-web-notification@w3.org, w3@norbertlindenberg.com

You wrote:
>See the other thread. Even if we allow setting it, that does not mean
>it's a) available, b) actually end up getting used by the notification

The information about the used language is important when the Web
Notification is not in the default language. As blind user of an
iphone I already experience the problem of getting notifications
pushed and spoken in the wrong language. It makes them completely

The information about the used language has to be available on a web
page already now  because web pages themselves have to provide
language information (WCAG 2.0 Guideline 3.1) (language of the

The potential  implementation for the web could be using an html
container (e.g. div) which is marked as a WAI-ARIA live region. This
would make any appearing notification in the browser spoken
This means the information is available and can be used - and must be
used to create an accessible web notification.

Because this standard is about "Web" Notifications, the current
built-in capabilities of accessible browsers will work out of the box.
This means language and directions would work without any additional

Here a possible implementation which would push informations via
javascript into a Web Notification container:
<div class="WebNotificationContainer" lang="ar"  dir="rtl"
role="status" aria-live="polite">
<div class="notification" data-tag="mail">
<img class="icon" src="red.gif" alt="wichtig" lang="de-DE" dir="ltr" />
< h1 class="title" lang="de" dir="ltr">Neue Nachricht"</h1>
<p class="body" lang="de" dir="ltr">Bitte melden sich sich in der
Botschaft in Kairo.</p>

The default system language spoken for Web Notifications in this
example would be Arab (lang="ar") with the textual direction
right-to-left (dir="rtl").
The incoming important mail in German would be read with an Arab
text-to-speech (TTS) engine if the language wouldn't have been
If the direction wouldn't have been specified the text would be
displayed in the wrong direction.
Did you try to listen to a German text with a Arab TTS? You need a lot
of fantasy to understand anything.

By providing the language and direction for title, icon alternate text
and the notification  the screen reader reads the message in German
including the information that the icon is an "important" signaling

You can already now try this example on an iphone. The iphone comes
with several languages including Arab and German. It has already
support for WAI-ARIA live regions and you can already now access the
system notification via javascript in the browser. There is nothing
which would stop an accessible implementation already now. This can be
tried by anyone  switching on the VoiceOver functionality on any
iphone. If tis is already possible on a mobile device there isn't any
excuse to not demand an accessible version for any Web Notification

I additionally would disagree in regards of the icon  not providing
information. Already now little flags and colours provide information
about the kind of message coming in. Blind and visually impaired users
wouldn't be able to get this potentially important information.
If the icon isn't important why is it in the specification at all? The
 favicon of the web tab is available anyways. The icon is only used if
it is different of the standard favicon of the notifiying web tab
(origin). If there is a need for a different icon from the favicon -
the icon obviously convays important information.

I fully agree events can be implemented in an accessible way. This is
the basic idea of principle 2 of the WCAG 2.0. But mentioning "click"
as an  event in a standard is the wrong message to the implementor. If
the W3C wants developers to use accessible events and therefore device
independent events  - we shouldn'T mention device-dependent events
which imply a specific inaccessible device.
If the Web Notification would be implemented literally according to
this document, I wouldn't be able to close the notification with a
keyboard.  In my experience accessibility fails mostly because
developers are not aware of the consequences of such little

By missing the possibility in the standard to specify the used
language and direction, and an alternate text for an icon (including
language and direction), we hinder an accessible implementation and
are  contradicting with the W3C approach of making all protocols and
formats accessible.

To ensure an accessible implementation of Web Notifications the
standard should refer to accessible implementation guidelines. Some
basic missinterpretations of this standard can make the use of Web
Notifications inaccessible or cause harm for photo sensitive users.



2012/7/4, Anne van Kesteren <annevk@annevk.nl>:
> On Sun, Jul 1, 2012 at 1:24 AM, Artur Ortega <Artur@ortegalink.com> wrote:
>> *  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.
> See the other thread. Even if we allow setting it, that does not mean
> it's a) available, b) actually end up getting used by the notification
> platforms.
>> 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
> The notification icon, like the favicon, is not content.
>>   The Web Notification document mentions additionally that the
>> notification " object offers a click event".  A click event is not a
>> device independent event.
> It is actually. It entirely depends on how it's implemented and
> there's no reason it cannot be implemented in a sane way.
> --
> http://annevankesteren.nl/
Received on Wednesday, 4 July 2012 21:13:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:14 UTC