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

Re: Is longdesc a good solution?

From: David Poehlman <david.poehlman@handsontechnologeyes.com>
Date: Fri, 5 Sep 2008 22:03:32 -0400
Message-ID: <78328FEF3B3640FDBCB38D6FFE8D3072@HANDS>
To: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>, "John Foliot" <foliot@wats.ca>
Cc: <public-html@w3.org>, "'W3C WAI-XTECH'" <wai-xtech@w3.org>

I see one problem with this that has already been mentioned. That is since 
it is not widely encountered on the web, many will not know what a long 
description is.

If I see a text link, it would have to be well labeled for me to know that 
it is a descriptive link.  if I see a longdesc associated with a link, I 
don't have to make a leap.

----- Original Message ----- 
From: "Lachlan Hunt" <lachlan.hunt@lachy.id.au>
To: "John Foliot" <foliot@wats.ca>
Cc: <public-html@w3.org>; "'W3C WAI-XTECH'" <wai-xtech@w3.org>
Sent: Friday, September 05, 2008 5:29 PM
Subject: Re: Is longdesc a good solution?



John Foliot wrote:
> Lachlan Hunt wrote:
>> John Foliot wrote:
>>> First off, many users of AT today do not query for longdesc as it is
>>> rarely
>>> if ever provided - a chicken and egg problem accelerated by the fact
>>> that most (all?) browsers today still do not natively support this
>>> element,
>> This is not a flaw in the study.  It's is precisely one of the
>> problems I designed the study to reveal.  But if you're just going to
>> concede that this is indeed the case, then we can conclude that
>> longdesc is not a well designed solution, and that it doesn't meet
>> the needs of users, and move on.
>
> This is *NOT* what I said, and to read that into my statement is simply
> wrong.   There is absolutely no proof that the design of @longdesc is poor 
> or
> flawed as it has never really been given a chance to flourish...

It seems like you are misunderstanding something about what I'm saying,
but it's not clear to me what exactly. So let me try to explain this to
you as clearly as I possibly can.

These are the facts:

1. Recent versions of assistive technology do support accessing the
    longdesc attribute.  This includes at least the latest versions of
    JAWS and Windows Eyes.

2. The existing users of these are therefore capable of accessing the
    longdesc attribute. These are the users, and *only* these users, that
    I will be referring to below.

Note that versions assistive technology that do not support the longdesc
attribute are not relevant. For the purpose of this study, this
eliminates the problem with the level of deployment of recent versions
and your complaint that "it has never really been given a chance to
flourish".

This is what we need to know:

When the users are reading a page with images that have long descriptions:

1. Do the users actually query the longdesc attribute and subsequently
    read the long descriptions?

2. When the users encounter a plain text link to a long description, do
    the users follow the link and read the description?

3. Are users more likely to read descriptions linked to with the
    longdesc attribute or a plain text description link?


This is what the answers to those questions will reveal.

1. If the answer is yes for a given user, then the longdesc attribute
    is useful.  Otherwise, it is not.

2. If the answer is yes for a given user, then plain text description
    links are useful.  Otherwise, they are not.

3. The answer to this will either indicate which is more useful to
    users, or be inconclusive.  This should be based on statistical
    analysis of the results.


Methodology:

This is a slightly revised methodology from the previous proposal, but
still along the same lines.

The group of users to be tested needs to comprise people who meet the
following conditions:

1. Require the use of assistive technology for browsing the web.

2. Are considered to be in the set of users for whom long descriptions
    are most useful.

3. Regularly use and are familiar with recent versions of assistive
    technologies that do support the longdesc attribute.

4. Have skill levels in a range that is representative of typical users.
    Assuming skill levels fit into a bell curve, this would be people
    within about 1 to 2 standard deviations from the mean.

The more users that can be tested, the better the results will be.
Since the users are assumed to know how to use their assistive
technology, they are not to be given any additional training
specifically for the purpose of the test, which could bias the results.

We need to set a set of baseline feature requirements for the assistive
technologies that can be used. I'll leave this as an exercise for those
who are more familiar with them.

There are 2 possible ways this can be performed.  The first is to divide
the users into 2 groups, as I previously suggested, and have 1 group
perform the test on pages that use the longdesc attribute and the other
group on the same set of pages, but using plain text links instead.

The second is to perform the test with one group and complete the test
on a set of pages using the longdesc attribute, and then repeat the test
on a different set of pages using description links.

The users should be led to believe that this is a general purpose
usability study of a website, rather than an explicit study of long
descriptions.  The sample website should be as realistic as possible and
include a reasonable number of pages; roughly the number they would find
on a small business website (probably about 4 or 5).

The test:

Each round will be performed in the same way:

1. Present the users with a set of questions that will they will be
    asked to answer based on reading the pages.  This lets them know what
    information they need to look for.

    The questions should ask about information within the pages including
    information that can be obtained from:
    a. The alt attributes.
    b. The long descriptions.
    c. The surrounding text.

    The purpose of the questions is to encourage the user to fully
    navigate the site looking for information, without explicitly telling
    them where to go or how to get there.

2. Present the users with the the sample website that they need to
    navigate.

    The users must not be explicitly told that they need to access the
    long descriptions and the the questions should not explicitly reveal
    which pages they need to access.  Basically, they need to navigate
    the site looking for information by themselves as they normally
    would on a real site.

3. Have the user complete the questionnaire.  They can do this while
    they navigate the site, instead of waiting till after.  If they
    cannot answer a question, they are allowed to leave it blank.

Perform the second round using pages with description links instead of
longdesc attributes.  If this is done with the same group of users, the
sample website and questions should be different.  If it's a different
group of users, use the same set of pages and questions, only modified
to swap the longdesc for description links.

Beyond this, further qualatitive analyisis could be performed to find
out why the users did or did not access the long descriptions.  If they
didn't, this could be for a number of reasons, such as failing to know
about that feature of their AT, or assuming the longdesc wouldn't be
present and not bothering to check, or perhaps because they missed it
due to their navigation strategy.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Received on Saturday, 6 September 2008 02:04:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC