Contents

<cyns> SF: alt text. I looked
back at the wai concensus doc, and it reflected what I was
saying in the WAI PF meeting yesterday

<cyns> RS: I hate
longdesc

<cyns> JS: I think we agreed
to obsolete longdesc

<cyns> SF: that path requires
behavior for aria-described-by that weren't agreed to by ppl
like Rich

<cyns> RS: in the
accessibiltiy API, all described by is is a relationship that
will take you somewhere in your doc, anywhere you want it to. I
hate the idea of putting a link in there and forcing the
browser to take the link.

<cyns> JS: force, or offer to
the browser?

<cyns> SF: I thought it was
just an offer

<cyns> RS: ok, that's
better.

<cyns> SF: in the case where
the longdesc has ref and id that's on a link, and the link text
is further description, provide a mechnaism for the user to be
albe to navigate teh link. A mechnanism whereby te user can
move to the structured content

<cyns> RS: no problem with
taht

<cyns> SF: a number of ID
references could be a problem. Describedby is just supposed to
concatenate text from multiple references.

<cyns> RS: if the content is
hidden, tehre's nowhere to go to. it'll be in the dom but not
in teh API

<cyns> RS: if it's hidden, UA
will fill in MSAA description with whatever text it can gleen.
It's like help text, can work with tooltip or whatever. But,
the current interface in JAWS provides a mechanism to go to the
descriptin.

<cyns> SF: The way to go
there needs to be specked out for the AT vendor.

<cyns> JS: because longdesc
was not a success

<cyns> RS: what about if
there's more than one IDREF for description? That's not spec'd,
and needs to be.

<cyns> SF: we could provide a
set of steps. EG if the ID is on a table, move to table, if
it's on a link provide an option to activate the link, if it's
just a text container, just read out the content.

<cyns> MC: just allow normal
processing, just go to the described by section. if there's a
link, the user can click/activate it.

<cyns> RS: we can't make AT
vendors do it.

<cyns> CS; no w3c specs for
AT, hole

<cyns> RS: there is history,
reasons for this.

<cyns> RS: AT vendors
wouldn't follow first UAAG spec

<cyns> SF; need to revisist
what we've said in text alternative document

<cyns> SF: provide idea in
implementiaon guide on how we think AT should implement it.

<cyns> CS: put AT guidelines
in UAG? or separate doc? good idea, but increase in scope

<cyns> RS: good luck getting
them to do it.

<cyns> CS: took 10 years with
browsers, maybe time to start with AT?

<cyns> JS; existing mechanism
(longdesc) is a failure, look at why, build from that

<cyns> SF: some AT and
browser vendors did implement longdesc

<cyns> SF: if we provide a
better mechanism, they may implement it.

<cyns> JS: part of why we
like ability to point via href via aria-describedby, is that we
could do various media, not just text

<cyns> SF: if you have a long
text alternative relationship, if there are 1 or 10 things
you're pointing to, the user can get access to those things

<cyns> JS: jst like any 1 or
10 hrefs on a web page, no a special case

<cyns> RS: can you give me an
example where you'd need more than one described-by?

<cyns> SF: one image that's
more than one table? A graph, a data table in html that
provides the data, that's the sort of relationship that a user
would want to know about

<cyns> CS: multiple
alternative versions for cognitive, like a picture, a video, a
shorter version of the text, etc.

<cyns> RS: so, we need to say
that if there are multiple IDREFs, each is an alternative
description. AT can then bring up a list box, and you can pick
the one you want.

<cyns> SF: agree

<cyns> JS: list should tell
you want mime type it is

<cyns> RS: would have to be
in a target

<cyns> CS: sounds like a
may

<cyns> JS: I'd accept a MAY,
or a SHOULD

<cyns> RS; do we want to put
in in the spec?

<cyns> what about mainstream
UA? should we ask them to do that?

<cyns> CS: yes, I think
so

<cyns> RS: in the spec, make
that a should or a may for now. When IE or FF does it, HTML5
will follow

<cyns> resolved: Multiple
IDREF in an aria-describedby MUST be interpreted as multiple
alternative rendereings, AT and other UA may expose mime-type
to the user, non-AT UA SHOULD provide a mechanism for
navigating to the IDREF

<cyns> RESOLVED: Multiple
IDREF in an aria-describedby MUST be interpreted as multiple
alternative rendereings, AT and other UA may expose mime-type
to the user, non-AT UA SHOULD provide a mechanism for
navigating to the IDREF

<scribe> scribe: janina

js: open agenda today, any topics
for us?

rs: someone should be designated
to start submitting changes from our spread sheet

cs: the mappings?

rs: yes, we're taking ian's and
redoing it, so create an issue, make this change, etc

cs: i was thinking putting the
entire table in as a change request

rs: were you planning to cover
this on aria call?

cs: could

rs: should probably run on the
aria group

cs: didn't we decide this at our
f2f?

js: for our santa clara f2f?

cs: would like to get it to html
wg before then
... at the very least i'd like to have this ready to submit by
f2f