Action-970 [PF] Publish F2F Minutes Extract RE ARIA-Describedby

The following is taken from the minutes of the WAI_PF Face to Face on 5
March and is being made public pursuant to a resolution of PF recorded
in Action-970:
http://www.w3.org/2012/03/05-pf-minutes.html#action05

This extracted discussion pertains to the citations identified in the
email thread beginning at:
http://lists.w3.org/Archives/Public/wai-xtech/2012Feb/0033.html

The above was also forwarded as public comments to PF:
http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html


Extract from the
  Protocols and Formats Working Group Teleconference
  05 Mar 2012

    Attendees

Present
    +1.512.973.aaaa, Cooper, Janina_Sajka, Rich_Schwerdtfeger,
    Joseph_Scheuhammer, Jon_Gunderson, James_Craig, +1.512.973.aabb,
    Cynthia_Shelly, James_Nurthen, Andi_Snow-Weaver, Mary_Jo_Mueller,
    Ann_Abbott, AlexQiangChen, David_Bolter, jongund, Tom_Brunet, jcraig
Regrets
Chair
    Janina_Sajka
Scribe
    MaryJo, cyns, janina, Rich, Andi, Andi_Snow-Weaver


JS: ... Looking at HTML citations are in order. Was sent to public comments
last night.

<AndiSnow> http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html

<jnurthen> scribeNick: jnurthen

JS: Need to look at what the HTMLWG folks have seen in our docs which
have led them to conclusions that this all will work fine

<AndiSnow> http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html

JS: This is something we don't need to to look at where these came from

<cyns> scribe:cyns

http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0002.html


      UAIG Last Call Comments Disposition, HTML 5 citations

We need to look at Leif's mail and find the places where the text is
unclear.

need to figure out what the right official process is.

<richardschwerdtfe>
http://www.w3.org/WAI/PF/aria-implementation/#include_elements

http://www.w3.org/WAI/PF/aria-implementation/#include_elements

<scribe> scribe: cyns

first HTML comment is
http://www.w3.org/WAI/PF/aria-implementation/#include_elements

This is what we were talking abou this morning.

<MichaelC> Comment 364
<http://www.w3.org/WAI/PF/Group/comments/details?comment_id=364>

we were silent on @hidden in the spec. this morning we added that
display:none, visibility:none, aria-hidden

SHOULD not be in the tree.

The cititation didn't include display:none; visibility:hidden, or @hidden.

does @hidden map to role presentation?

does the HTML 5 spec say so?

<richardschwerdtfe>
http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html

no, presentation is not mapped to @hidden

<janina> scribe: janina

rich: as i read it, they say must not, and we just agreed on shouldn't
... their equiv in html5 is hidden none
... we could say for host langs that explicitly say somethng should be
hidden, that content should not be exposed to a11y

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

cyns: we tend to agree html's issue-204 seem appropriate, regardless of
longdesc

rich: so mod to uaig, something like "if host lang semantics that define
hidden must not be exposed to a11y api"
... "however if determined by aria-hidden alone, it's a should not"
... reason can't put the text in the dom is that it can't be walked
... can't nav it because it's hidden
... when we do describedat, will ask browsers for a vehicle to render
that location

cyns: implementing this feature makes it act exactly like ie's longdesc,
markup is flattened into string text

<MichaelC> I've entered the comments from the message as 8 discrete
comments:
https://www.w3.org/WAI/PF/Group/comments/list?comment_id[]=363&comment_id[]=364&comment_id[]=365&comment_id[]=366&comment_id[]=367&comment_id[]=368&comment_id[]=369&comment_id[]=370

<MichaelC> a few said "no comment" so I didn't add anything

<richardschwerdtfe> Proposal: Any host language native semantic for
hidden (display:none, visibility:hidden, HTML5 @hidden) that states that
an element is hidden, the element and its descendants MUST NOT appear in
the accessibility tree. An element market that is hidden solely through
the provision of an aria-hidden attribute set to "true" SHOULD NOT be
exposed as an object in the accessibility tree. The exclusion in the
accessibility tree includes its descendants.

thanks, michael

<clown> "element *marked*'

<richardschwerdtfe> Proposal: Any host language native semantic for
hidden (display:none, visibility:hidden, HTML5 @hidden) that states that
an element is hidden, the element and its descendants MUST NOT appear in
the accessibility tree. An element that is hidden solely through the
provision of an aria-hidden attribute set to "true" SHOULD NOT be
exposed as an object in the accessibility tree. The exclusion in the
accessibility tree includes its descendants.

Now looking at next item -- 2 of 9

<clown> 2 of 9 is:
http://www.w3.org/WAI/PF/aria-implementation/#mapping_additional_relations_reverse_relations

thanks, clown

<clown> my pleasure janina

agreement in room to add language 'unless hidden re sec 5.1. ...'

now discusing wether we actually are in agreement ...

considering content visible only when requested ...

dscribedby and labeledby have the extra feature that grabs a string

for 5.6.3.2

<richardschwerdtfe> A reverse relation exists when an element's ID is
referenced by a property in another element. For APIs that support
reverse relations, user agents MUST use the mapping defined in the
following table when an element's ID is referenced by a relation
property of another element and element corresponding to the element's
ID is exposed as an object in the accessibility tree.

<richardschwerdtfe> A reverse relation exists when an element's ID is
referenced by a property in another element. For APIs that support
reverse relations, user agents MUST use the mapping defined in the
following table when an element's ID is referenced by a relation
property of another element and element corresponding to the element's
ID is exposed as an object in the accessibility tree as defined in
section 5.1.1.

<annabbott> cys: All ARIA references must point to an element that is
exposed as an accessible object in the accessibility tree. When the
referenced object is not exposed in the accessibility tree (e.g. because
it is hidden <link>, the reference is null. aria-labelledby and
aria-described by have an additional feature, which allows them to pull
a flattened string from the referenced element to populate...

<annabbott> ...the accname or accdescription fields of the accessibility
API. This feature is described in the Name Calculation section <link>.

<clown> ;-)

rich: if something isn't exposed in the a11y tree, there's no mapping

cyns: the confusion comes from the referenced ones, not the others

now to 3 of 9

<clown> http://www.w3.org/WAI/PF/aria-implementation/#mapping_role_table

<clown> ^ 3 of 9

cyns: we may want to consider whether reverse relations is the correct
locus for the above ...

rich: think if it's hidden, it's not mapped
... my surmisal based on the html comments i see

asw: so not every section, but more than once, so where?

rich: suggest a note
... just to make sure another errant thread isn't waiting to be pulled

now 4 of 9

<clown> 4 of 9:
http://www.w3.org/WAI/PF/aria-practices/#Descriptions_external

rich: we need to take the reference to the link out

jn: we use this a lot, something very similar, a description of a screen
shot
... we use longdesc

clown: this is to get the same result via describedby

cyns: so an example, this one good, this one not may be the needed
clarification.

jn: a wcag failure technique
... it works fine if visible, and good for that

<richardschwerdtfe> *ACTION:* joseph Modify section 4.1.2.3 in the APG
to limit the cases where the "d link" example does not work when the
description is "hidden" per the ARIA 1.0 glossary definition of hidden
[recorded in http://www.w3.org/2012/03/05-pf-minutes.html#action04]

<trackbot> Created ACTION-969 - Modify section 4.1.2.3 in the APG to
limit the cases where the "d link" example does not work when the
description is "hidden" per the ARIA 1.0 glossary definition of hidden
[on Joseph Scheuhammer - due 2012-03-12].

now 5 of 9

<clown> http://www.w3.org/WAI/PF/aria-practices/#Descriptions_tooltip

<MichaelC> action-969: for comment 366
https://www.w3.org/WAI/PF/Group/comments/update?comment_id=366

<trackbot> ACTION-969 Modify section 4.1.2.3 in the APG to limit the
cases where the "d link" example does not work when the description is
"hidden" per the ARIA 1.0 glossary definition of hidden notes added

jn: a lot of code for something fairly simple

cyns: needs to be focusable

rich: anything to change here?

cyns: don't think so, but need to point out this doesn't solve the problem

rich: far too much work--more work than dlinks
... far too much work for the author

agreement in room: longdesc and describedat are preferable to this
because they're so very much simpler

simpler means it happens more often, and it's correct more often

<clown>
http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description

now on 6 of 9

cyns: no examples of using longdesc in our doc, because ours is an aria
doc, and longdesc examples need to be in the html docs

jn: we have more ...

cyns: it's true that describedby ws designed to solve problems not
solved by longdesc, but it was to handle certain shortcomings not a full
replacement
... point that describedby is for in page references

rich: describedby exists because visible descriptions usually accompany
figures
... in these circumstances authors don't want to create another page
with that content

cyns: navigation still jumps

jn: so describedby goes on more elements than just image

mc: the earlier discussion was that describedby becomes overloaded if we
try to have it accept both internal and external references

<Zakim> MichaelC, you wanted to say we can start ARIA 1.1 now, we just
have to consider impact on the 1.0 timeline

<clown> brb

We're regathering ...

<richardschwerdtfe> scribe: Rich

<richardschwerdtfe> Rich: Response text to 6 of 9 as to why longdesc was
not covered by aria-describedy - We originally defined aria-describedby
with the assumption that off-page content was handled elsewhere.

<richardschwerdtfe> Rich: leaf blower says hi

<clown>
http://www.w3.org/WAI/PF/aria-practices/#kbd_layout_remaining_description

<richardschwerdtfe> Rich: This is the response?

<richardschwerdtfe> Michael: yes

<richardschwerdtfe> Rich: we should remove this text: "This is unlike
longdesc which typically requires the author to create a separate file
to describe a picture. It is preferable to have the descriptive text in
prose as well so that it is readily available to all users. Yet, like
longdesc, descriptive text is treated separately from the short name
provided by the title or alt attributes in HTML. "

<richardschwerdtfe> jonG: In jaws they concatenate the description with
the label

<richardschwerdtfe> cynthia: for an image though?

<richardschwerdtfe> jonG: I am not sure about an image

<richardschwerdtfe> janina: what foliot had been saying is
accedescription is auto read

<richardschwerdtfe> cynthia: he does say "why this is preferable?"

<richardschwerdtfe> Rich: We can say we like aria-describedby for
visible descriptions as web developers did not like having to create
another page for the description and because cognitively impaired users
could often get confused when having to switch context to go to another
page to get the description.

<richardschwerdtfe> Rich: Hidden text is not readily available to all
users. It is not available to visual users. Hidden text was only
supported because Freedom Scientfic was directing developers to supply
special JAWS attributes to provide help text that could be applied to
individual form elements. We allowed for hidden content to be used for
accessible descriptions to aid blind users and standardize the feature.

<richardschwerdtfe> Rich: With respect to alt and longdesc, it is not
the responsibility of the ARIA Authoring Practices Guide to document how
to use the accessibility features of HTML. So, if we did not document
fully either ALT or longdesc that is acceptable. Perhaps an Authoring
Practices Guide should be created for HTML 5.

<clown> 7 of 9
http://www.w3.org/WAI/PF/aria/states_and_properties#aria-describedby

<richardschwerdtfe> jon: for aria-describedby on an image the JAWS
key+alt+r reads the description upon user request. It also tells you
that a description is present.

<clown> 8 of 9:

<clown> http://www.w3.org/WAI/PF/aria/roles#textalternativecomputation

<clown> Skip hidden elements unless the author specifies to use them

<clown> > via an aria-labelledby or aria-describedby being used in the
current

<clown> > computation.

<richardschwerdtfe> jon: in this version of NVDA there is not a command
for getting the description but I don't know that I have the latest version

<richardschwerdtfe> cynthia: the text alternative computation talks
about how to compute the text string. It is clear. There is a difference
between accessible objects in the tree an the string

<richardschwerdtfe> janina: is there any objection to extracting this
portion of the minutes and exposing it to wai-xtech?

<richardschwerdtfe> RESOLUTION: no objection

<richardschwerdtfe> *ACTION:* Janina: Respond to wai-xtech discussion on
the use aria-describedby for longdesc [recorded in
http://www.w3.org/2012/03/05-pf-minutes.html#action05]

<trackbot> Created ACTION-970 - Respond to wai-xtech discussion on the
use aria-describedby for longdesc [on Janina Sajka - due 2012-03-12].

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Tuesday, 6 March 2012 19:11:36 UTC