Re: Expanding longdesc use

On Thu, 15 Mar 2012 23:18:29 +0100, David Singer <singer@apple.com> wrote:

>
> On Mar 15, 2012, at 15:09 , Leif Halvard Silli wrote:
>
>> David Singer, Thu, 15 Mar 2012 11:30:40 -0700:
>>> On Mar 15, 2012, at 11:05 , David MacDonald wrote:
>>>> There has been some discussion about describedby as a replacement
>>>> for longdesc. However, screen reader user would have to encounter
>>>> the description twice (once on the image and once on the page),
>>>> which by definition is "long". The long text on the page clutters
>>>> the page for most sighted users. (a deterrent for implementation by
>>>> webmasters)
>>>
>>> I think you are bumping up against a tension here that we have never
>>> really resolved.  It lies between
>>>
>>> "you haven't really provided for accessibility unless there are
>>> features that are explicitly and exclusively there for accessibility"

I think this is an unfair characterisation. There are certain things that  
may be needed for accessibility, whether or not they are needed for  
anything else. If you haven't done those things, you haven't provided for  
accessibility as well as you should have.

>>> "provisions which are invisible to the non-accessibility user and
>>> author tend to be poorly authored; accessibility as a natural
>>> consequence of good design for everyone is a better goal"
>>>
>>> I think a goal of having descriptions, transcripts, alternative text,
>>> alternative media, available and potentially useful to everyone would
>>> be good, myself -- I lean towards the second.

Sure.

>> If you meant that one could rather have used a visual text link, then
>> you are right - that is almost always possible - technically speaking.
>> But that was not what David M was discussing: He discussed what to do
>> when it has been concluded - by the designer or whoever - that there
>> should be no visual link.

> But 'normal content' is often not 'visible' today anyway - common web  
> design hides stuff and does appealing appearance (slide-in, and so on)  
> when wanted.

Right...

> I am not sure I agree with either of (a) if the description is part of  
> the 'normal content' it'll annoy 'normal users'

That's not the issue here. If the description is in the normal flow, then  
it fails to resolve the accessibility issue it is purported to address.  
The use case for an optional extra description is where it is not helpful  
to have to wade through the content to get to the next piece, but the user  
will sometimes need to be able to get that content. So it doesn't just  
annoy 'normal users'. Given the difference between visual scanning at  
various levels of perceptual ability, and navigating as a blind user, it  
is likely to annoy blind users much more than people with designer-type  
vision.

> or (b) the affordance, if needed, that shows the description, should
> be specific to accessibility users.

It shouldn't. And isn't. Except if you use a piece of software that didn't  
make this available to most users, (such as many browsers).

> Both the content and the affordance may need *identifying* ('this
> links to the long description of that'), and again, not really
> specifically for accessibility users, though their software needs
> this discoverable link.

Right.

cheers

-- 
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg kan litt norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Friday, 16 March 2012 15:49:11 UTC