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

Re: Expanding longdesc use

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 14 Mar 2012 19:17:34 +0100
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Janina Sajka <janina@rednote.net>, Judy Brewer <jbrewer@w3.org>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, LĂ©onie Watson <lwatson@nomensa.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
Message-ID: <20120314191734854175.2cf821c8@xn--mlform-iua.no>
Laura Carlson, Wed, 14 Mar 2012 12:06:24 -0500:

>> Could we expand your CP - now
> 
> I am open updating the CP if:
>
> 1. The accessibility task force agrees and comes to consensus
>    that it is the best way to help successfully reinstate 
     longdesc into HTML; and
> 2. If someone volunteers to draft solid use cases; and
> 3. If someone volunteers to draft additions for the spec text and
>    those additions obtain task force consensus.
> 
> So for number one,  Silvia, Leonie, Janina and other task force
> members, would you support expanding longdesc? And if so under what
> circumstances? <img>, <table>, global? What is the scope?

> If this all happens, I will be delighted to update the Change Proposal.

Laura, and all, I hope the following doesn't break your conditions:

Re 1: To limit @longdesc to only that single element that
      *defaults* to role 'img', makes the credibility of the
      current CP lower: It is less consistent. To allow
      @longdesc on any element that takes role 'img' thus
      should increase the chances of the CP. 

      Q: Could we, before anything else, reach consensus on
         1. Allowing longdesc for any role 'img' element?
         2. That this increase the CP's credibility?

Re 2: We don't need new usecases for role=img elements: At least
      from an A11Y API point of view, there is no difference 
      between <img alt=text > and <p role=img aria-label=text >.
      So, OK we could still offer such use case, but they could
      be boilerplate copies of the CP's current use cases.

      Q: Do we agree that extending longdesc to any element of role=img
         1. Does not require that we write new use cases that, on a
            fundamental level, differ from what we have now?
         2. That we, anyhow, should demonstrate how to use longdesc
            on images such as ASCII art, <object role=img> and 
            <div role=img><svg/></div> ?

Re 3. Spec text: I am willing to go through the current texts -
      I could work on a separate copy - to update it so that it
      consistently covers any element of role 'img'. 

      Q: Do we agree that limiting @longdesc to elements of role
         'img', would significantly lower the extra work?
      
Regarding 'global': By agreeing on the above points, we have already 
covered <table role=img longdesc=l>.

But to also extend longdesc to <table>, in general, regardless of the 
role the table, is going to cause a good deal work and discussion. E.g. 
it could make the semantics of @longdesc diffuse and unclear. We could 
of course discuss it. But please, let us agree/disagree about the 
lowest fruit first: role=img.

At next level, we could try to agree that 'application' and 'document' 
needs @longdes. This, too, would include <table>. As well as <video> 
and <audio> - with or without role=application. However, even to allow 
longdesc for role 'application' and role 'document', is probably going 
to require a some debate. For instance: Should we - similar to @title - 
give separate meaning to @longdesc, depending on which elemetn it is 
used on? Consider <video>: Should longdesc then descript the poster 
image? Or the entire video? Or ...

For that reason, I - once again - strongly suggest that we verify that 
we agree about allowing @longdesc for elements of role='img' before 
looking at the other options. Agreeing on role=img first, should 
increase the chances on agreeing about the rest.
-- 
Leif Halvard Silli
Received on Wednesday, 14 March 2012 18:18:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:27 UTC