W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: conflation of issues or convergence of interests?

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Sun, 29 Jul 2007 12:10:38 +1000
Message-ID: <46ABF71E.3010800@lachy.id.au>
To: Sander Tekelenburg <st@isoc.nl>
CC: public-html@w3.org

Sander Tekelenburg wrote:
> At 12:53 +1000 UTC, on 2007-07-28, Lachlan Hunt wrote:
>> bandwidth limitation, for example, is not an accessibility issue.
> 
> Again depends on your dictionary. When bandwidth restrictions prohibit you 
> from accessing a resource, you have no access. A textual equivalent is likelt 
> to be accessible then still.

This issue is discussed in this article.

http://accessites.org/site/2006/10/the-great-accessibility-camp-out/

I fit into Camp 2, as described in that article.  The term web 
accessibility refers to issues relating to disabilities.  That doesn't 
mean I don't care about other types of issues, just that I don't group 
them under that term.  From the article (emphasis added):

   The general goal of the W3C is to make the Web available
   to everyone, regardless of the device, platform, network,
   culture, geographic location, or physical or mental ability
   of those using it. Collectively, these goals are referred
   to as *universality*. To ensure these goals are met, the W3C
   has many initiatives, such as the Internationalisation (I18n)
   Activity, the Device Independence Group, and the Web
   Accessibility Initiative. The WAI’s role is to ensure that
   the web is accessible to people with disabilities:

     "The Web Accessibility Initiative (WAI) works with
      organizations around the world to develop strategies,
      guidelines, and resources to help make the Web
      accessible to people with disabilities."
      -- WAI http://www.w3.org/WAI/about-links.html

Universality is a much broader and more appropriate term when discussing 
issues related to everyone.  It is much more useful to keep the term 
accessibility in a narrower scope, relating only to disabilities.

>> For the video example, [...]  For example, there a couple of
>> possible solutions:
>>
>> * Providing an ordinary link to the description alongside the video
>>    pro: already possible and easy to do.
>>    pro: makes it available to anyone who wants it, not just those with
>>         assistive technology that exposes it.
>>    con: ?
> 
> Another con is that this would be similar to the having @alt and an image's
> caption being the same, as we discussed earlier. Alternatives are to be
> chosen from, not to be presented as if they are complimentary. You don't want
> your alt text rendered next to the image. You want to provide/consume
> *either* one (at a time).

I disagree with that comparison.  In some cases, it is appropriate to 
show both as complimentary.  Here's an example of a presentation I 
published earlier this year.

http://lachy.id.au/dev/presentation/future-of-html/

Both the audio and the transcript are available to everyone, and are 
complimentary for several reasons.

* A user may want to listen to the audio and follow along in the transcript.
* A user may want to quote a portion of it and the transcript allows 
them to easily copy and paste.
* A user may want to quickly reference some section of the speech, which 
is easier to do in the transcript than it is to seek to the right place 
in the audio.

But the transcript is also an alternative to the audio for users who 
can't hear it.

>> * Nesting the alternative content within the video.
>>    pro: the content is semantically associated with the video
> 
> pro: it can be marked up, unlike something like @alt. It can thus be made to
> 'look better' (which seems likely to be an incentive for authors to bother to
> try to provide a textual equivalent).

That also applies to the other alternative because you can mark up the 
content however you like in the alternative page that gets linked to.

> pro: no special attribute needed to specify the semantic link with the video.

The need for the explicit association isn't yet conclusive, but that's 
effectively the same as the pro I already gave above: "the content is 
semantically associated with the video".

>>    con: may not be readily available to anyone who wants it, only those
>>         with assistive technology that exposes it.
> 
> Why? You don't need Jaws to get access to an alternate. Your average GUI
> browser can provide access to @alt through some mechanism

I said *readily available*.  Perhaps I should have said easily instead. 
  Selecting properties from the context menu and then reading the alt 
text in the dialog box is not particularly easy or discoverable for many 
users.  However, unlike video or audio, it's rare that users who can see 
the image would want to read the alt text.  But with multimedia, there 
are a variety of reasons why a user would choose the alternative format 
even if they could access the media.

Consider how difficult it is for a user to access the alternative 
content nested within <object>.  AFAIK, the only way to do so in most 
graphical browsers is to view the source.  So, if an audio file was 
embedded using <object> (or <audio>) and the transcript was nested 
within, that would make it difficult for users without assistive 
technology to access it.

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Sunday, 29 July 2007 02:10:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT