RE: 48-Hour Consensus Call: InstateLongdesc CP Update

Doesn't the HTML 5 WG take a pretty strong stance against specifying browser UI in the spec?  For example, there is no detail on how to render the new required attribute of the input element.

Personally, I like the "little i," but I think the decision of how to render longdesc visually should be up the browsers.  It seems out of scope for the HTML spec.

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: Tuesday, September 25, 2012 4:54 AM
To: Leif Halvard Silli
Cc: John Foliot; David Singer; HTML Accessibility Task Force
Subject: Re: 48-Hour Consensus Call: InstateLongdesc CP Update

On Tue, Sep 25, 2012 at 9:38 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:
> Silvia Pfeiffer, Tue, 25 Sep 2012 13:06:58 +1000:
>> On Tue, Sep 25, 2012 at 12:21 PM, Leif Halvard Silli:
>>> Silvia Pfeiffer, Tue, 25 Sep 2012 11:48:44 +1000:
>>>> On Tue, Sep 25, 2012 at 11:04 AM, John Foliot:
>>>>> James Craig wrote:
>>>
>>>>> I'm more concerned about a link in that hidden frame, or perhaps 3 
>>>>> or 4 links, and how/what will happen with tab-focus.  For a screen 
>>>>> reader to be able to afford the user the ability to fire a link, 
>>>>> it must first receive tab-focus. Yet those tab-focusable links are 
>>>>> hidden to the sighted user.
>
>>>> you can't have it both ways:
>
>>> Did you mean "or it is is accessibility content, then it is not 
>>> __accessible__ to anything but _screenreader users_" ?
>>
>> Yes, screenreader users and any tools that rely on the a11y API of browsers.
>
>>> So I don't think John's concern is "how to have it both ways". 
>>> Rather, it is how to make sure that users only get it a single way.
>>
>> My point was: what if for a particular Website the owner decides that 
>> the long description is not relevant to be exposed visually, but 
>> would still like to provide it to the a11y API. Thus, if we *require* 
>> it both ways, we will end up getting nothing.
>
> I think you point to a problem with the iframe technique: iframe is 
> not meant for the A11Y API alone - not unless one isolates it via hidden=""
> and use aria-descriedby="" or similar (why not longdesc=""!) to point 
> to it. So using iframe is, effectively, a 'both ways' technique.

No, iframes are fine since they are hidden from view. I don't like iframes for other reasons - I would prefer we actually have an explicit a11y solution for long descriptions rather than having everyone write their own, because they can be found by a web crawler.

Instead, I was pointing to the request to have a visual encumbrance for @longdesc, something that Web devs do not want. Browser settings are outside the scope of Web devs, so don't count in this context. So, if a web dev wants to provide a long description for an image, but does not want a visual encumbrance, then they won't use @longdesc because that implies (at least for some users) a visual encumbrance.

Regards,
Silvia.

Received on Tuesday, 25 September 2012 22:21:00 UTC