aria-describedat?

[david bolter]

I was just told a new attribute is being proposed called "aria-describedat"
which expects a URL value. We could expose this via IA2/ATK object
attributes. Feedback wanted. Note this might eventually put the longdesc
debate to rest.

Cheers,
David

[Alexander Surkov]

longdesc is exposed as accessible action. If aria-describedat is
supposed to replace longdesc then we should expose it the same way. I
didn't follow the discussion about aria-describedat vs longdesc so
what's the result of it?
Alex.

> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility

[david bolter]

I didn't follow it either. Anyone?

D

[Benjamin Hawkes-Lewis]

On Tue, Mar 13, 2012 at 4:02 PM, david bolter <david....@gmail.com> wrote:
> I didn't follow it either. Anyone?

The HTML a11y TF (a joint effort of PFWG and HTML WG) at least
nominally supports a Change Proposal to make @longdesc conforming in
HTML5.

PFWG is also investigating specifying an aria-describedat ARIA property.

To say the least, it's not clear that @aria-describedat is a
functional replacement for @longdesc.

ARIA is in practice used to communicate to AT; @longdesc is supposed
to be exposed to all users via mainstream browser UI.

With that in mind, would there be any interest in tackling:

https://bugzilla.mozilla.org/show_bug.cgi?id=longdesc

Perhaps along the lines of:

http://my.opera.com/chaals/blog/tell-me-more

Or even a more basic implementation as in iCab and Opera?

I don't see why a name change should make a difference here, but if
there's no interest in implementing browser UI for @longdesc, would
there be any interest in implementing such UI for @aria-describedat?

Original thread:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0015.html

--
Benjamin Hawkes-Lewis

[Joseph Scheuhammer]

On 12-03-13 11:27 AM, Alexander Surkov wrote:
> longdesc is exposed as accessible action.

Good to know.

Part of the inspiration for aria-describedat was a claim that
aria-describedby could be used instead of @longdesc. The ARIA working
group disagrees with that assessment: aria-describedby is for
descriptions that are on the same page as the accessible they are
describing, and is exposed as the accessible description property in the
a11y API.

I've wondered that if aria-describedby == accDescription, then what does
longdesc correspond to? Exposing it as an accessible action makes
sense, since the user experience is to go to another page for the
description. It acts like a link (sort of).

Is that what "exposed as an accessible action" means, Alex?

Thanks.

--
;;;;joseph.


'A: After all, it isn't rocket science.'
'K: Right. It's merely computer science.'
- J. D. Klaun -

[Alexander Surkov]

Yeah, iirc, we had a patch to make aria-describedby acting as longdesc
but never landed it. So if ARIA is going to have aria-describedat for
that then we could pick it up.

Currently longdesc action opens a new window with the longdesc URI.

Alex.

[Charles McCathieNevile]

On Tue, 13 Mar 2012 17:17:07 +0100, Benjamin Hawkes-Lewis
<bhawke...@googlemail.com> wrote:

> On Tue, Mar 13, 2012 at 4:02 PM, david bolter <david....@gmail.com>
> wrote:
>> I didn't follow it either. Anyone?

> [bunch of good sense]

> I don't see why a name change should make a difference here, but if
> there's no interest in implementing browser UI for @longdesc, would
> there be any interest in implementing such UI for @aria-describedat?

Which is a motivation for proposing @aria-describedat - if people are
prepared to do it, I offered to make the spec work happen. It *is* pretty
much the same thing, but sometimes even a stupid change makes a
difference, and really, getting the functionality is far more interesting
than being 'right' but not having anything useful to show for it...

cheers

Chaals

> Original thread:
>
> http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0015.html
>
> --
> Benjamin Hawkes-Lewis

> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility

--
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

[Joseph Scheuhammer]

On 12-03-13 3:35 PM, Charles McCathieNevile wrote:
> It *is* pretty much the same thing

Nit and possible benefit: @aria-describedbyat can be used with any
element. @longdesc is restricted to <img> only.

Or, possible implementation headache :-)

[Benjamin Hawkes-Lewis]

On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <cl...@alum.mit.edu> wrote:
> On 12-03-13 3:35 PM, Charles McCathieNevile wrote:
>>
>> It *is* pretty much the same thing
>
> Nit and possible benefit:  @aria-describedbyat can be used with any element.
>  @longdesc is restricted to <img> only.
>
> Or, possible implementation headache :-)

Spec writers are as free to allow @longdesc on other elements as they
are to mint new attributes and allow them on other elements.

For example, one idea under discussion at HTML WG would allow
@longdesc to link to transcriptions for <video> elements.

--
Benjamin Hawkes-Lewis

[Jason White]

Joseph Scheuhammer <cl...@alum.mit.edu> wrote:

> I've wondered that if aria-describedby == accDescription, then what
> does longdesc correspond to? Exposing it as an accessible action
> makes sense, since the user experience is to go to another page for
> the description. It acts like a link (sort of).

Disclosing it as an accessible action, if I understand the API correctly,
should also be compatible with the case in which the image is a link and also
possesses an @longdesc or @aria-describedat (whichever is adopted) attribute.

Of course, it's then the responsibility of the AT to present the description
action appropriately, but that's a straightforward matter of implementation.

I would argue that the HTML and PF WGs should specify either @longdesc or
@aria-describedat, but not both; we don't want authors to use both attributes
with URIs that, inadvertently perhaps, refer to different resources.

My broader attitude to this entire issue is in line with Charles
McCathieNevile's position, but I also worry that the attention and debate whic
it is generating are disproportionate to the importance of the problem. I
think this focus on @longdesc risks deflecting resources away from larger
concerns affecting HTML 5, such as the discussion about the proper use and
accessibility implications of CANVAS.

[Silvia Pfeiffer]

The biggest problem I see with @longdesc is that it is exposed as text
in the IE DOM and as a link in other browsers. So, for backwards
compatibility reasons there can't be a interoperable implementation of
how to expose @longdesc in browsers. Accessibility APIs have dealt
with this issue and are converting IE's text to a link, so it's not a
problem for a11y, but only for browsers. Also, there aren't any
consistent ways of how to expose @longdesc in browser UIs - this was
always left to the browsers and browsers have mostly ignored the need
to expose it or implemented diverging solutions.

So, moving to a new attribute name, recommending consistent ways of
how to expose the link visually, and applying that attribute to more
than just the <img> element might help with getting off-page
descriptions for complex HTML elements.

All of this is, of course, dependent on browser & a11y API/tool
implementations. If there is no support for such a new attribute, the
whole discussion is moot.

Cheers,
Silvia.

[Benjamin Hawkes-Lewis]

On Wed, Mar 14, 2012 at 12:40 AM, Jason White <ja...@jasonjgw.net> wrote:
> I would argue that the HTML and PF WGs should specify either @longdesc or
> @aria-describedat, but not both; we don't want authors to use both attributes
> with URIs that, inadvertently perhaps, refer to different resources.

There are plenty of places where ARIA already duplicates HTML
semantics (e.g. navigation landmark versus <nav>, @aria-label versus
@alt on an <img>, @aria-required versus @required).

Such duplication is justifiable in two ways:

1. ARIA is intended to be used with markup languages other than HTML,
therefore it should cover all semantics required to make documents and
applications accessible. (It doesn't actually do this, but then ARIA
has always been in identity crisis.)

2. In practice, mainstream user agents implement ARIA as a way to
communicate to accessibility APIs or AT using the DOM. They do not
base user interface on ARIA features. For example, @required triggers
user interface feedback in Firefox, but @aria-required only affects
the accessibility API mapping. I'd expect that if @aria-describedat
were specified, it would follow this pattern of implementation. That
would make it unsuitable for recommendation as a sufficient technique
for long description provision, since all users need to be able to
access long descriptions on demand, not just AT users. However,
native markup language semantics such as @longdesc could have an
implicit semantic of @aria-describedat. In the case where both are
specified, I'd expect @aria-describedat to win in terms of what is
mapped to the accessibility API.

One can argue that these characteristics (theoretical reusability and
communication to ATs only) are undesirable, but if you do so it's hard
to understand what you think is the point of adding in any new ARIA
features rather than just tidying up what's already there. Gaps in the
semantics of the web platform can be filled directly in the relevant
specs (HTML, SVG, MathML).

I'm ambivalent about whether we should specify @aria-describedat; my
key point is to stress that I don't think it's a @longdesc replacement
since I don't think implementors will create browser UI for it (but
this thread is an opportunity to be proved wrong).

> My broader attitude to this entire issue is in line with Charles
> McCathieNevile's position, but I also worry that the attention and debate whic
> it is generating are disproportionate to the importance of the problem. I
> think this focus on @longdesc risks deflecting resources away from larger
> concerns affecting HTML 5, such as the discussion about the proper use and
> accessibility implications of CANVAS.

This sort of FUD harms @longdesc and does not help <canvas>.

Please address deficiencies you see in <canvas> directly, by filing
bugs or providing feedback on the available spec proposals.

See especially:

* Issue 205: Define what author guidance and/or methods should be
provided to those that wish to create accessible text editors using
canvas as a rendering surface.

http://www.w3.org/html/wg/tracker/issues/205

There are two Change Proposals under consideration:

http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelectionRevised

http://www.w3.org/wiki/No_edit_change_proposal_for_canvas_text_editing

* Issue 201: Provide canvas location and hit testing capability to
fallback content

http://www.w3.org/html/wg/tracker/issues/201

Frank's produced a Change Proposal:

http://www.w3.org/wiki/Canvas_hit_testing

Ian is working a spec for an addHitRegion method:

http://wiki.whatwg.org/wiki/Canvas#Regions

--
Benjamin Hawkes-Lewis

[Benjamin Hawkes-Lewis]

On Wed, Mar 14, 2012 at 7:06 AM, Silvia Pfeiffer
<silviap...@gmail.com> wrote:
> On Wed, Mar 14, 2012 at 9:44 AM, Benjamin Hawkes-Lewis
> <bhawke...@googlemail.com> wrote:
>> On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <cl...@alum.mit.edu> wrote:
>>> On 12-03-13 3:35 PM, Charles McCathieNevile wrote:
>>>>
>>>> It *is* pretty much the same thing
>>>
>>> Nit and possible benefit:  @aria-describedbyat can be used with any element.
>>>  @longdesc is restricted to <img> only.
>>>
>>> Or, possible implementation headache :-)
>>
>> Spec writers are as free to allow @longdesc on other elements as they
>> are to mint new attributes and allow them on other elements.
>>
>> For example, one idea under discussion at HTML WG would allow
>> @longdesc to link to transcriptions for <video> elements.
>
> The biggest problem I see with @longdesc is that it is exposed as text
> in the IE DOM and as a link in other browsers. So, for backwards
> compatibility reasons there can't be a interoperable implementation of
> how to expose @longdesc in browsers. Accessibility APIs have dealt
> with this issue and are converting IE's text to a link, so it's not a
> problem for a11y, but only for browsers.

This is thoroughly confused. The DOM representation is precisely the
same in all popular browsers (.longdesc property with a string value).
The representation to accessibility APIs is different between Firefox
and Internet Explorer with this as with many other things, and AT that
support long descriptions handle those differences. Such
representations are worth standardising to free up competition, and
that's precisely what the HTML to Accessibility APIs mapping
specification will do. In any case, the differences in accessibility
API representations are not a problem for browsers seeking to
implement UI on top of @longdesc, since browser UI does not depend on
the accessibility API representation.

> Also, there aren't any
> consistent ways of how to expose @longdesc in browser UIs - this was
> always left to the browsers and browsers have mostly ignored the need
> to expose it or implemented diverging solutions.

iCab and Opera both expose @longdesc via the context menu. The same
implementation was proposed for Gecko in 2000 and for WebKit in 2007.

I think a better implementation would provide additional ways to
discover longdesc, but in general it's problem has not been that
people have been unable to think of any way to expose it.

--
Benjamin Hawkes-Lewis

[Jason White]

Silvia Pfeiffer <silviap...@gmail.com> wrote:

> So, moving to a new attribute name, recommending consistent ways of
> how to expose the link visually, and applying that attribute to more
> than just the <img> element might help with getting off-page
> descriptions for complex HTML elements.

I agree.

Concerning <video>, the use case would presumably be what WCAG 1.0 refers to
as a "collated text transcript" of the video. This was dropped as a
requirement in WCAG 2.0 even at the highest (AAA) level of conformance. As a
result, users who are deaf-blind and for whom captions and auditory
descriptions are inadequate, are deprived of access even at the strongest
conformance level.

I remember arguing that the requirement should be retained for exactly this
reason (at level AAA of WCAG conformance). Unfortunately, it's a debate which
I and others lost outright when the working group made its decision.

Of course, it would be possible to allow the "fall-back" content of <video> to
carry a description, without adding @longdesc or @aria-described-at; the HTML
5 draft, when last I looked, explicitly discouraged this practice in both
<audio> and <video>.

While I would welcome HTML support for collated transcripts of video, I think
their removal from WCAG will weaken the case - perhaps arguments from
consistency and universality of whatever design is chosen, will ultimately
prove decisive, but that could be misplaced hope on my part.

[Jason White]

Benjamin Hawkes-Lewis <bhawke...@googlemail.com> wrote:

> 1. ARIA is intended to be used with markup languages other than HTML,
> therefore it should cover all semantics required to make documents and
> applications accessible. (It doesn't actually do this, but then ARIA
> has always been in identity crisis.)

My recollection is that it was also designed as an interim solution, until
such time as the necessary features were added to the underlying markup
languages. Trends in recent years suggest that the interim is going to be a
very long one indeed, however.

> I'm ambivalent about whether we should specify @aria-describedat; my
> key point is to stress that I don't think it's a @longdesc replacement
> since I don't think implementors will create browser UI for it (but
> this thread is an opportunity to be proved wrong).

I don't think there's a consensus, or anything close to it, about which
accessibility requirements should be supported by a browser UI, and which
should be handled by browser extensions or other AT tools that, among other
capabilities, respond to Aria attributes. Without clarity on this point, it
will be harder to reach agreement about whether an Aria attribute can serve as
a sufficient @longdesc substitute, and this surely isn't the only such issue.

>
> > My broader attitude to this entire issue is in line with Charles
> > McCathieNevile's position, but I also worry that the attention and debate whic
> > it is generating are disproportionate to the importance of the problem. I
> > think this focus on @longdesc risks deflecting resources away from larger
> > concerns affecting HTML 5, such as the discussion about the proper use and
> > accessibility implications of CANVAS.
>
> This sort of FUD harms @longdesc and does not help <canvas>.

It isn't fud. It's a claim about prioritization of limited resources within a
constrained time-frame and the impact of such priority decisions on
accessibility over-all. The emergence of user interfaces written in Canvas
(e.g., GTK 3, LibreOffice, pdf.js, just to mention examples that have come to
my attention as under development) raises serious concerns about how canvas
will be used and whether inaccessible applications will be deployed before the
accessibility-related problems associated with Canvas are resolved.

Of course, such examples might not be the start of the trend; one could well
argue that entire UIs aren't supposed to be written in Canvas; but we know
also that trying to constrain how the Web application development community
uses a new feature is not always a successful strategy.

>
> Please address deficiencies you see in <canvas> directly, by filing
> bugs or providing feedback on the available spec proposals.

I'll be monitoring the Canvas discussion and contributing if I think I have
something worthwhile to say on the matter.

[Loretta Guarino Reid]

Jason,

WCAG 2.0's Success Criterion 1.2.8 requires an alternative for time-based
media<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#alt-time-based-mediadef>(that
is, the collated text transcript) at level AAA.

Loretta

[Benjamin Hawkes-Lewis]

On Tue, Mar 13, 2012 at 4:17 PM, Benjamin Hawkes-Lewis
<bhawke...@googlemail.com> wrote:
> With that in mind, would there be any interest in tackling:
>
>    https://bugzilla.mozilla.org/show_bug.cgi?id=longdesc
>
> Perhaps along the lines of:
>
>    http://my.opera.com/chaals/blog/tell-me-more
>
> Or even a more basic implementation as in iCab and Opera?
>

> I don't see why a name change should make a difference here, but if
> there's no interest in implementing browser UI for @longdesc, would
> there be any interest in implementing such UI for @aria-describedat?

OK, so disappointing radio silence so far; allow me to push the
conversation in a slightly different direction.

Let's say that to get a universally accessible hidden long description
link we came up with a design including an accessibility API mapping,
a context menu action, a hover effect, and a button somewhere in the
browser chrome that appears when long descriptions are present in the
page and provides access to long descriptions to keyboard/switch users
who can't hover over images.

Is it socio-politically feasible for someone (let's say me - for the
sake of argument) to implement this in Firefox so that all Firefox
users will have access to long descriptions?

If so, what would be the best way to go about actually implementing
it? Presumably there are gatekeepers (e.g. Asa Dotzler) who have an
influence on what does or does not go into Firefox's chrome. What's
the procedure for getting such gatekeepers on side? What's the
procedure for getting their feedback on the design?

Would a name change to the attribute make the slightest bit of
difference to the feasibility of actually doing this?

If there's no chance that Mozilla would even consider adding ambient
features to Firefox's user interface to support long descriptions for
all, then we're wasting our time discussing this.

--
Benjamin Hawkes-Lewis

[Alexander Surkov]

> If so, what would be the best way to go about actually implementing
> it? Presumably there are gatekeepers (e.g. Asa Dotzler) who have an
> influence on what does or does not go into Firefox's chrome. What's
> the procedure for getting such gatekeepers on side? What's the
> procedure for getting their feedback on the design?

I think file a bug, cc gatekeepers and ask them for feedback.
Alex.

On Wed, Mar 14, 2012 at 4:37 PM, Benjamin Hawkes-Lewis

[Benjamin Hawkes-Lewis]

On Wed, Mar 14, 2012 at 8:42 PM, Alexander Surkov
<surkov.a...@gmail.com> wrote:
>> If so, what would be the best way to go about actually implementing
>> it? Presumably there are gatekeepers (e.g. Asa Dotzler) who have an
>> influence on what does or does not go into Firefox's chrome. What's
>> the procedure for getting such gatekeepers on side? What's the
>> procedure for getting their feedback on the design?
>
> I think file a bug, cc gatekeepers and ask them for feedback.

We could likely use the existing bug, but who would be the gatekeepers
to put in the loop?

--
Benjamin Hawkes-Lewis

[Alexander Surkov]

Well I think different teams at Mozilla should take a look like UI
team, maybe security team and HTML w3c gurus. I'd suggest to ping
David Bolter in the bug so he could cc right people.
Alex.

[david bolter]

I'm right here :)

Did anyone ever write an addon? Should be straightforward and would help
move forward.

D
On Mar 14, 2012 5:11 PM, "Alexander Surkov" <surkov.a...@gmail.com>

[Benjamin Hawkes-Lewis]

On Wed, Mar 14, 2012 at 9:17 PM, david bolter <david....@gmail.com> wrote:
> I'm right here :)
>
> Did anyone ever write an addon? Should be straightforward and would help
> move forward.

Well, I've linked to the addon that Charles wrote for Opera to give
some idea of what I have in mind.

Patrick Lauke wrote a longdesc addon that just adds a context menu
action a million years ago:

https://addons.mozilla.org/en-US/firefox/addon/longdesc/

I've toyed with the idea of writing an addon, but I'm not entirely
clear if it would move things forward or not. Patrick's attempt all
those years ago doesn't seem to have helped much. In particular, I'm
worried that the existence of an addon gives the impression that this
functionality does not need to built in to browsers so as to be
available at the point of use.

Do you really think putting together a new addon would help?

At the very least, I should imagine anyone putting effort into this
would want some sort of buy-in from Firefox gatekeepers that some sort
of built-in UI might be appropriate further down the line.

--
Benjamin Hawkes-Lewis

[david bolter]

Popular addons definitely get attention for in-product consideration.
Cheers,
D
On Mar 14, 2012 5:42 PM, "Benjamin Hawkes-Lewis" <

[Alexander Surkov]

I don't think this add-on will beat records. We deal here with
chicken-egg problem: browsers don't support, web authors don't use it.

I don't have strong opinion about UI for longdesc. If the spec doesn't
require the browser to do that then we need to delegate the answer of
this question to HTML w3c gurus at Mozilla. From accessibility point
of view we always can provide a special support it for ATs.

Alex.

[david bolter]

Yeah I wanted to write some of this but wasn't using a real keyboard. You
are exactly right to draw attention to the chicken and egg problem, and my
comment about popular addons was not meant to be specific to longdesc or
describedat.

All, I've mostly avoided the longdesc debate since there are so many other
things on our plates that are worthwhile and easier to move forward. I
looked at bug 1996 years ago. I'd say whatever we do, we need to avoid
repeating the long history of debate. All that's really left is mockups,
code, or addons.

Mozilla Firefox is a community run project and I suspect I would consider
most of the people on this list part of the community. Some discussion of
influence is here: http://www.mozilla.org/about/roles.html That page links
to module owners etc.

Cheers,
D

[Silvia Pfeiffer]

On Thu, Mar 15, 2012 at 8:41 AM, Benjamin Hawkes-Lewis

<bhawke...@googlemail.com> wrote:
> On Wed, Mar 14, 2012 at 9:17 PM, david bolter <david....@gmail.com> wrote:
>> I'm right here :)
>>
>> Did anyone ever write an addon? Should be straightforward and would help
>> move forward.
>
> Well, I've linked to the addon that Charles wrote for Opera to give
> some idea of what I have in mind.
>
> Patrick Lauke wrote a longdesc addon that just adds a context menu
> action a million years ago:
>
>   https://addons.mozilla.org/en-US/firefox/addon/longdesc/
>
> I've toyed with the idea of writing an addon, but I'm not entirely
> clear if it would move things forward or not. Patrick's attempt all
> those years ago doesn't seem to have helped much. In particular, I'm
> worried that the existence of an addon gives the impression that this
> functionality does not need to built in to browsers so as to be
> available at the point of use.
>
> Do you really think putting together a new addon would help?
>
> At the very least, I should imagine anyone putting effort into this
> would want some sort of buy-in from Firefox gatekeepers that some sort
> of built-in UI might be appropriate further down the line.

No opposition to the idea in the first place to me seems to also be
some indication that the gatekeepers don't really care.

I guess the only way to find out is to write the patch and try to land it.

I agree with you that spending time on a plugin is really a waste of
time, since it doesn't solve the core problem.

If you have the cycles, I'd encourage you to write the patch. In my
mind, the name of the attribute is indeed secondary. Primarily I want
the functionality implemented. If we can get an implementation of
@longdesc support in a way that it really should be done and that is
applicable to other elements, too, then we are in a better position to
move forward. If eventually the attribute is given a different name in
the spec and applied to other elements, adapting that code to cover
both the legacy @longdesc and the new attribute is really a minor
problem.

HTH.

Cheers,
Silvia.

[Alexander Surkov]

I'd say it makes sense to try to get an attention of gatekeepers prior
you start hacking. Otherwise you have good chances you spent a time
but they aren't going to take your patch ever.
Alex.

[Jason White]

Loretta Guarino Reid <loretta...@google.com> wrote:
> WCAG 2.0's Success Criterion 1.2.8 requires an alternative for time-based
> media<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#alt-time-based-mediadef>(that
> is, the collated text transcript) at level AAA.

Excellent - it must have been re-introduced subsequently.

In that case there's a stronger argument for markup language support and the
discussion can proceed to the question of whether new features are needed.

[Jason White]

Silvia Pfeiffer <silviap...@gmail.com> wrote:

> I guess the only way to find out is to write the patch and try to land it.
>
> I agree with you that spending time on a plugin is really a waste of
> time, since it doesn't solve the core problem.
>
> If you have the cycles, I'd encourage you to write the patch. In my
> mind, the name of the attribute is indeed secondary. Primarily I want
> the functionality implemented. If we can get an implementation of
> @longdesc support in a way that it really should be done and that is
> applicable to other elements, too, then we are in a better position to
> move forward. If eventually the attribute is given a different name in
> the spec and applied to other elements, adapting that code to cover
> both the legacy @longdesc and the new attribute is really a minor
> problem.

I think this would be the most productive way to proceed. Having an
implementation is a stronger position to occupy when standardizing a feature
and it should help to identify any issues that need to be resolved.

[JF]

On Mar 14, 2:41 pm, Benjamin Hawkes-Lewis

<bhawkesle...@googlemail.com> wrote:
> I've toyed with the idea of writing an addon, but I'm not entirely
> clear if it would move things forward or not. Patrick's attempt all
> those years ago doesn't seem to have helped much. In particular, I'm
> worried that the existence of an addon gives the impression that this
> functionality does not need to built in to browsers so as to be
> available at the point of use.
>
> Do you really think putting together a new addon would help?

Howdy,

FWIW, it can't hurt. I have actually discussed this with a few
developers who have the chops i lack to actually get something like
this in action, but as is often the case there is a time-factor.

In discussion with Dirk Ginader (Yahoo!), we had batted around the
idea of placing a visual indicator in the address-bar (similar to how
the Tails microformats plugin works, or when a page contains an RSS
feed), that would be the visual indicator that a longdesc'd image
exists on the page - this borrows on the TellMe More extension that
@chaals wrote for Chrome. Dirk had previously knocked together a
jQuery plugin on my urging that demonstrated a way of drawing back the
@longdesc content into the same page (using AJAX) - it can be found on
github (https://github.com/ginader/Accessible-Longdesc) and a demo is
here: http://blog.ginader.de/dev/jquery/longdesc/examples/webaim/index.php

>
> At the very least, I should imagine anyone putting effort into this
> would want some sort of buy-in from Firefox gatekeepers that some sort
> of built-in UI might be appropriate further down the line.

+1

JF

[Laura]

Hi David and all,

> All that's really left is mockups, code, or addons.

Some references:

Mockups for the rendering section of HTML5:
http://www.d.umn.edu/~lcarlson/research/ld-rendering2.html

longdesc addons:
http://www.d.umn.edu/~lcarlson/research/ld-ua.html

Hope this helps.

Best Regards,
Laura
--
Laura L. Carlson

["Francisco Javier Dorado Martínez"]

Hi all

As an end user mainly, I would like to have long descriptions
for objects, for an image or link, or video etc.
Assistive technology would advice me there is a description for the
object, and I would use the extended information show command. E.G. "Where
am I" in Orca screen reader.
So longdesc would be presented like an ATKObject description.
I don't know if this have some sense :-)

Just my 2 cents.
Regards,
Javier

On Wed, March 14, 2012 5:10 pm, david bolter wrote:
> Yeah I wanted to write some of this but wasn't using a real keyboard. You
> are exactly right to draw attention to the chicken and egg problem, and my
> comment about popular addons was not meant to be specific to longdesc or
> describedat.
>
> All, I've mostly avoided the longdesc debate since there are so many other
> things on our plates that are worthwhile and easier to move forward. I
> looked at bug 1996 years ago. I'd say whatever we do, we need to avoid

> repeating the long history of debate. All that's really left is mockups,
> code, or addons.
>

> Mozilla Firefox is a community run project and I suspect I would consider
> most of the people on this list part of the community. Some discussion of
> influence is here: http://www.mozilla.org/about/roles.html That page
> links
> to module owners etc.
>
> Cheers,
> D
>
> On Wed, Mar 14, 2012 at 5:55 PM, Alexander Surkov <
> surkov.a...@gmail.com> wrote:
>
>> I don't think this add-on will beat records. We deal here with
>> chicken-egg problem: browsers don't support, web authors don't use it.
>>
>> I don't have strong opinion about UI for longdesc. If the spec doesn't
>> require the browser to do that then we need to delegate the answer of
>> this question to HTML w3c gurus at Mozilla. From accessibility point
>> of view we always can provide a special support it for ATs.
>>

>> Alex.

>>
>> On Wed, Mar 14, 2012 at 5:48 PM, david bolter <david....@gmail.com>
>> wrote:
>> > Popular addons definitely get attention for in-product consideration.
>> > Cheers,
>> > D
>> >

>> > On Mar 14, 2012 5:42 PM, "Benjamin Hawkes-Lewis"

>> > <bhawke...@googlemail.com> wrote:
>> >>
>> >> On Wed, Mar 14, 2012 at 9:17 PM, david bolter
>> <david....@gmail.com>
>> >> wrote:
>> >> > I'm right here :)
>> >> >
>> >> > Did anyone ever write an addon? Should be straightforward and would
>> help
>> >> > move forward.
>> >>
>> >> Well, I've linked to the addon that Charles wrote for Opera to give
>> >> some idea of what I have in mind.
>> >>
>> >> Patrick Lauke wrote a longdesc addon that just adds a context menu
>> >> action a million years ago:
>> >>
>> >> https://addons.mozilla.org/en-US/firefox/addon/longdesc/
>> >>

>> >> I've toyed with the idea of writing an addon, but I'm not entirely
>> >> clear if it would move things forward or not. Patrick's attempt all
>> >> those years ago doesn't seem to have helped much. In particular, I'm
>> >> worried that the existence of an addon gives the impression that this
>> >> functionality does not need to built in to browsers so as to be
>> >> available at the point of use.
>> >>
>> >> Do you really think putting together a new addon would help?
>> >>

>> >> At the very least, I should imagine anyone putting effort into this
>> >> would want some sort of buy-in from Firefox gatekeepers that some
>> sort
>> >> of built-in UI might be appropriate further down the line.
>> >>

>> >> --
>> >> Benjamin Hawkes-Lewis

>>
> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>

--

Correo enviado desde webmail.

[Silvia Pfeiffer]

I think somebody needs to come up with a nice transparent overlay icon
that is somewhat meaningful. For example something with an arrow and
some text lines. The indicator for availability of long descriptions
needs to be both obvious and non-obstructive. Anyone know a good
designer?

Silvia.