Re: PFWG comments on Web Notifications

> On Dec 11, 2013, at 9:37 AM, Michael Cooper <cooper@w3.org> wrote:
> 
> Thank you for your responses to the comments received from the Protocols and Formats Working Group. The view of the WG is inline below.
> 
> On 05/12/2013 8:50 PM, Jon Lee wrote:
>> [This is a draft WG reply to the PFWG's last call comments. Comments on the proposed resolution are welcome; if no one objects in a week’s time, this will be the WG’s official response to his comment. -Jon]
>> 
>> On Oct 9, 2013, at 9:21 AM, Michael Cooper <cooper@w3.org <mailto:cooper@w3.org>> wrote:
>> 
>>> Below are two comments from the Protocols and Formats Working Group on Web Notifications Last Call Working Draft of 22 September 2013 http://www.w3.org/TR/2013/WD-notifications-20130912/ <http://www.w3.org/TR/2013/WD-notifications-20130912/>. PFWG approval to send these comments is archived at https://www.w3.org/2013/10/09-pf-minutes.html#item04 <https://www.w3.org/2013/10/09-pf-minutes.html#item04> (Member-only link right now, should become public in a week).
>>> 
>>> Comment 1
>>> 
>>> 4.2 states - The notification <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'s language <http://www.w3.org/TR/2013/WD-notifications-20130912/#language> specifies the primary language for the notification <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'s title <http://www.w3.org/TR/2013/WD-notifications-20130912/#title> and body <http://www.w3.org/TR/2013/WD-notifications-20130912/#body>. Its value is a valid BCP 47 language tag, or the empty string. The empty string indicates that the primary language is unknown. [LANG] <http://www.w3.org/TR/2013/WD-notifications-20130912/#refsLANG>"
>>> 
>>> We should add a Note to state that if the primary language is unknown this would be a WCAG violation.
>> 
>> Software often interacts with, transmits, and presents text without knowing which human languages are used in the text. Notification services frequently utilize this text to inform the user (e.g., that the user has received a new email), so we can't expect software to know the human languages used in notification text. We shouldn't require software to do something we're certain it can't accomplish.
> We understand this issue but also consider it important since the spec expressly permits a null language notification. We suggest this softened text to alert implementers: "Note that while the language may be unknown to the system, leaving it unset will create problems     for some users.”

Notifications need to be consistent with other parts of the Web platform. HTML5 defines the lang attribute and describes how to use it, but neither requires its use nor declares that leaving it unset creates problems. It’s best for us to be following HTML5 here, since most developers using the notifications API won’t know the language of the notification text.

>> 
>>> Comment 2
>>> 
>>> The API specifies the ability to supply an icon without the ability to specify any text alternative for the icon. We need an ability to provide alternative content for the icon. Given that notifications are created in JS more or less in real time, a plain string is enough (assuming that the internationalisation story is  
>>> really correct).
>> 
>> Please see prior discussion [1]. The icon’s purpose is decorative and provides no additional information. We should consider an editorial change to make this clearer.
> In the prior discussion you reference, we note that Artur Ortega provided counter-examples for how, notwithstanding the intent of the specification developers, these icons are often used to convey meaning. It appears that comment was not addressed and we support and echo it. 

I understand that developers may choose to do this, but if they explicitly ignore one requirement of the spec, it seems unlikely that they will follow other, equally ignorable requirements.

> While your intent may be for the icon to be purely decorative, we believe authors will use it in other ways and think it would be important for the spec to make it possible for authors to provide alternative text in such circumstances.

Fortunately, if a Web author violates the requirement that the icon be purely decorative, they have the option of using an image format which can carry its own text alternative, like SVG.

Given that the platform already makes this possible, no further spec changes are necessary here.

Jon