aria-describedat?

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

aria-describedat?

David Bolter-3
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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

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.

On Tue, Mar 13, 2012 at 11:15 AM, david bolter <[hidden email]> wrote:

> 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
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

David Bolter-3
I didn't follow it either. Anyone?

D

On Tue, Mar 13, 2012 at 11:27 AM, Alexander Surkov <
[hidden email]> wrote:

> 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.
>
> On Tue, Mar 13, 2012 at 11:15 AM, david bolter <[hidden email]>
> wrote:
> > 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
> > _______________________________________________
> > dev-accessibility mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
On Tue, Mar 13, 2012 at 4:02 PM, david bolter <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Joseph Scheuhammer-2
In reply to this post by Alexander Surkov
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 -

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

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.


On Tue, Mar 13, 2012 at 2:29 PM, Joseph Scheuhammer <[hidden email]> wrote:

> 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 -
>
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Charles McCathieNevile-2
In reply to this post by bhawkeslewis
On Tue, 13 Mar 2012 17:17:07 +0100, Benjamin Hawkes-Lewis  
<[hidden email]> wrote:

> On Tue, Mar 13, 2012 at 4:02 PM, david bolter <[hidden email]>  
> 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
> [hidden email]
> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Joseph Scheuhammer-2
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 :-)

--
;;;;joseph.


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

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Jason White-14
In reply to this post by Joseph Scheuhammer-2
Joseph Scheuhammer <[hidden email]> 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.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Silvia Pfeiffer
In reply to this post by bhawkeslewis
On Wed, Mar 14, 2012 at 9:44 AM, Benjamin Hawkes-Lewis
<[hidden email]> wrote:

> On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <[hidden email]> 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. 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.
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
In reply to this post by Jason White-14
On Wed, Mar 14, 2012 at 12:40 AM, Jason White <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
In reply to this post by Silvia Pfeiffer
On Wed, Mar 14, 2012 at 7:06 AM, Silvia Pfeiffer
<[hidden email]> wrote:

> On Wed, Mar 14, 2012 at 9:44 AM, Benjamin Hawkes-Lewis
> <[hidden email]> wrote:
>> On Tue, Mar 13, 2012 at 8:35 PM, Joseph Scheuhammer <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Jason White-14
In reply to this post by Silvia Pfeiffer
Silvia Pfeiffer <[hidden email]> 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.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Jason White-14
In reply to this post by bhawkeslewis
Benjamin Hawkes-Lewis <[hidden email]> 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.

_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

Loretta Guarino Reid
In reply to this post by Jason White-14
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

On Wed, Mar 14, 2012 at 1:21 AM, Jason White <[hidden email]> wrote:

> Silvia Pfeiffer <[hidden email]> 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.
>
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
In reply to this post by bhawkeslewis
On Tue, Mar 13, 2012 at 4:17 PM, Benjamin Hawkes-Lewis
<[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

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
<[hidden email]> wrote:

> On Tue, Mar 13, 2012 at 4:17 PM, Benjamin Hawkes-Lewis
> <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

bhawkeslewis
On Wed, Mar 14, 2012 at 8:42 PM, Alexander Surkov
<[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: aria-describedat?

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.

On Wed, Mar 14, 2012 at 4:57 PM, Benjamin Hawkes-Lewis
<[hidden email]> wrote:

> On Wed, Mar 14, 2012 at 8:42 PM, Alexander Surkov
> <[hidden email]> 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
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
12