Re: Discussion on Change Proposal for ISSUE-66

On Thu, Jan 21, 2010 at 6:12 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Jan 21, 2010, at 6:20 AM, Shelley Powers wrote:
>
>> On Thu, Jan 21, 2010 at 2:44 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> I don't understand why we would *forbid* UAs from improving image
>>> accessibility by whatever means they can.
>>>
>>> However I do agree with the change proposal in that I would be fine
>>> with removing the current text. However I would suggest replacing it
>>> with a general statement that UAs are allowed to improve accessibility
>>> in any way it can. Even if that goes against the letter of the spec.
>>>
>>> This is similar to how I think the spec should say that UAs should be
>>> allowed to deviate from the spec for security reasons if the UA so
>>> desires.
>>>
>>
>> That's a dangerous precedent to take.
>>
>> If a UA sees the potential for security risks in any of the specs, it
>> should be working, now, to ensure the component leading to the risk is
>> removed, or altered.
>
> My own feeling is that what Jonas says makes sense for accessibility, where making the best effort to give meaningful access to the content is more important than exact alignment on behavior details. It might even be worth an explicit sentence or two somewhere.
>
> But I'm not sure it makes sense for security to be treated the same way. It seems like having such a requirement would make it almost impossible to have a valid test suite, since there's no way to check whether a UA's intent in breaking a MUST requirement was security. It would effectively turn every spec requirement into a SHOULD.
>
> I think the right way to handle security issues with the spec is to violate the spec if necessary (since UAs will do that anyway), and seek a spec change. I don't think it is either necessary or sensible for the spec to grant license to violate itself.
>

I agree with you on the security issues. If there's any legitimate
reason to violate a spec it's because of security. However, it's best
to leave this for the spec equivalent of, "In case of fire, break
glass".

I think there are many paths to take to encourage UAs to increase
accessibility. Matt's point on this issue, if I may paraphrase him, is
that a reliance on a (non-existent) technology downplays the necessity
for authors to hold themselves accountable. The authors may read that
section and think to themselves, "Oh, I don't have to do anything
about the img alt attribute, because the technology will take care of
it for me".

And frankly, if a UA had this kind of wizbang technology, it wouldn't
need the HTML5 spec to tell them to use it. In fact, news of the
capability would be plastered all over the front page of Techmeme, and
brought up to the general exclamations of ooohs and aaahs.

It's probably best that the spec focus on tangibles, not future
advances in technology.

> Regards,
> Maciej
>
>

Received on Friday, 22 January 2010 00:43:30 UTC