Re: PFWG comments on Web Notifications

Updated response from PF inline below, which should close the comment:

On 17/12/2014 3:27 PM, Michael Cooper wrote:
> Thank you for your further response to the PFWG comments. Preliminary 
> feedback from the PFWG is inline below:
> On 12/12/2014 5:53 PM, Jon Lee wrote:
>>
>>> On Dec 11, 2013, at 9:37 AM, Michael Cooper <cooper@w3.org 
>>> <mailto: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/. PFWG 
>>>>> approval to send these comments is archived at 
>>>>> 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.2states - Thenotification 
>>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'slanguage 
>>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#language>specifies 
>>>>> the primary language for thenotification 
>>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'stitle 
>>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#title>andbody <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.
> Thank you for your explanation. After consideration, the PFWG has 
> accepted this rationale and your disposition of this issue, so it can 
> be closed.
>>
>>>>
>>>>> 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.
> The PFWG is still discussing this issue and has not yet come to 
> conclusion. The group plans to continue the discussion in early 
> January and send a completed response at that time. Please let us know 
> if you have timeline considerations impacted by this.
The PF understands your position on this. We are concerned that authors 
will misuse the icon, for example including a "error" or "warning" icon 
but not clarifying in the text of the notification that there is a 
difference. We accept that that the spec cannot normatively prevent 
that. You indicated in your original response that you could put in  
editorial guidance about this issue, and we will accept that as the 
solution. Therefore, we request that you put in a note like "Note: 
authors need to ensure that any meaning conveyed by the icon is also 
conveyed in the text of the notification."

This will close the comment. Thank you for your forbearance as we 
process this.

Michael
>
> Michael
>>
>>> 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
>