W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Leif H Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 19 Sep 2012 19:25:54 +0200
To: mjs@apple.com
Cc: bhawkeslewis@googlemail.com, joshue.oconnor@cfit.ie, silviapfeiffer1@gmail.com, faulkner.steve@gmail.com, john@foliot.ca, rubys@intertwingly.net, public-html-a11y@w3.org
Message-ID: <6957444108.1032549954@xn--mlform-iua.no>
Correct use is a concern to everyone. Even the instate CP try to help 
correct that problem. As an argument for a namechange those data are 
perfect. Leif

------- Opprinnelig melding -------
> Fra: Maciej Stachowiak <mjs@apple.com>
> Til: xn--mlform-iua@xn--mlform-iua.no
> Cc: bhawkeslewis@googlemail.com, joshue.oconnor@cfit.ie, 
> silviapfeiffer1@gmail.com, faulkner.steve@gmail.com, john@foliot.ca, 
> rubys@intertwingly.net, public-html-a11y@w3.org
> Sendt: 19/9/'12,  19:05
>
>
> I know that in the past people have questioned Ian Hickson's study of a 
> large corpus because it was not possible to independently reproduce the 
> results.
>
>  - Maciej
>
> On Sep 19, 2012, at 10:00 AM, Leif H Silli 
> <xn--mlform-iua@xn--mlform-iua.no> wrote:
>
>> Maciej, e.g. Janina did not reject Steve's findings. She only questioned 
>> their relevance. It would be more interesting - now - to conclude about: 
>> how to interpret the misuse and why it is negative or does not matter. 
>> Leif
>>
>> ------- Opprinnelig melding -------
>>> Fra: Maciej Stachowiak <mjs@apple.com>
>>> Til: bhawkeslewis@googlemail.com
>>> Cc: joshue.oconnor@cfit.ie, xn--mlform-iua@xn--mlform-iua.no, 
>>> silviapfeiffer1@gmail.com, faulkner.steve@gmail.com, john@foliot.ca, 
>>> rubys@intertwingly.net, public-html-a11y@w3.org
>>> Sendt: 19/9/'12,  18:43
>>>
>>>
>>> On Sep 19, 2012, at 3:11 AM, Benjamin Hawkes-Lewis 
>>> <bhawkeslewis@googlemail.com> wrote:
>>>
>>>> On Wed, Sep 19, 2012 at 11:07 AM, Joshue O Connor
>>>> <joshue.oconnor@cfit.ie> wrote:
>>>>>> I did not have time too look through it, but those I looked at 
>>>>>> either
>>>>>> contained only a "#" or they contained (another) image file. With
>>>>>> regard to the first (#) then I agree "misinformed" about the 
>>>>>> potential
>>>>>> negative effect. With regard to image URLs inside @longdesc, then 
>>>>>> there
>>>>>> are image light box solutions - libraries - that  more or less
>>>>>> consciously makes incorrect use of longdesc. (Today they would 
>>>>>> perhaps
>>>>>> picked at @data-foo attribute instead - but that was not 'valid' 
>>>>>> then.)
>>>>>> Of the few I scanned, no one contained text.
>>>>>
>>>>>
>>>>> Yikes, maybe it is the former Silvia. Thanks for doing that Leif. It 
>>>>> does
>>>>> therefore sound like an inappropriate sample population or at least
>>>>> partially so.
>>>>
>>>> How does the reason why longdesc was misused make it in an
>>>> inappropriate sample population for client software developers trying
>>>> to make a decision about whether to expose longdesc via UI to their
>>>> users?
>>>>
>>>> (My problem with these approaches to sampling is that randomly
>>>> sampling the web corpus doesn't match the pattern of usage by typical
>>>> users, it just tells you about long tail effects, so the relationship
>>>> with user impact is unclear.)
>>>
>>> Some browser vendors (including Apple) have the ability to gather data 
>>> on real-world usage as actually observed by users. Generally for privacy 
>>> considerations we cannot log individual URLs. But we could log data such 
>>> as:
>>>
>>> - What proportion of images have a longdesc attribute
>>> - What proportion of those images have obviously wrong longdesc URLs 
>>> (empty, #, appears to be an image, top-level URL of a domain, url of the 
>>> same page that contains the image, etc)
>>>
>>> Would folks see such data as more credible? It would be significant 
>>> effort and we could not reveal the raw numbers. I suspect many would 
>>> reject such data as not publicly reproducible.
>>>
>>> Regards,
>>> Maciej
>>>
>>>
>>
>>
>
Received on Wednesday, 19 September 2012 17:26:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 19 September 2012 17:26:52 GMT