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

Please include www-international@w3.org in this discussion.

Thanks,
Norbert


On Jul 4, 2012, at 14:12 , Artur Ortega wrote:

> Anne,
> 
> 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
>> platforms.
> 
> 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
> useless.
> 
> 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
> origin).
> 
> 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
> automatically:
> http://www.w3.org/WAI/PF/aria-practices/#LiveRegions
> 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
> effort.
> 
> 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>
> </div>
> </div>
> 
> 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
> specified.
> 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
> icon.
> 
> 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
> implementation.
> 
> 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
> differences.
> 
> 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.
> 
> Cheers
> 
> Artur
> 
> 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:51:18 UTC