- From: Artur Ortega <Artur@ortegalink.com>
- Date: Wed, 4 Jul 2012 22:12:54 +0100
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: public-web-notification@w3.org, w3@norbertlindenberg.com
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:13:22 UTC