- From: John Foliot <john@foliot.ca>
- Date: Fri, 20 Apr 2012 16:06:14 -0700
- To: "'Cynthia Shelly'" <cyns@microsoft.com>, "'Benjamin Hawkes-Lewis'" <bhawkeslewis@googlemail.com>
- Cc: "'Laura Carlson'" <laura.lee.carlson@gmail.com>, "'Janina Sajka'" <janina@rednote.net>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>, "'Joshue O Connor'" <joshue.oconnor@cfit.ie>, "'Judy Brewer'" <jbrewer@w3.org>, <david100@sympatico.ca>, "'Richard Schwerdtfeger'" <schwer@us.ibm.com>, "'James Nurthen'" <james.nurthen@oracle.com>, "'Leif Halvard Silli'" <xn--mlform-iua@xn--mlform-iua.no>, "'Jonas Sicking'" <jonas@sicking.cc>
Cynthia Shelly wrote: > > John, > Benjamin makes a good point. The flattened text is put in the > accessible description whether or not the referenced content is visible. > Does this concern you? Does having the authoring advice associated with > @hidden make sense? I'm ok with either way on this. No, I understood that the text was flattened to string text whether visible or @hidden, which was one of the main points my initial note tried to underscore: the AAPIs are going to process any of this content as string text, because that is how - at least to my understanding - the APIs were designed to work. They were not really designed to convey rich textual semantics, and so they drop those semantics (or rather, that richness is the responsibility of the browsers, which are built to render and express that richness, as HTML consuming tools). The concern is and always has been that some will see the ability to point to @hidden content using aria-describedby as a solution for richer descriptive content (well, that and the potential for overly verbose AccDescription content being forced upon the SR user). > > I like this proposed text, but don't want to destabilize our agreement. > Is this ok with you? > > All HTML elements may have the hidden content attribute set. The hidden > attribute is a boolean attribute. When specified on an element, it > indicates that the element is not yet, or is no longer, visible or > interactive. <del/>@hidden is equivalent to the CSS display:none > construct.</del> User agents should not render elements that have the > hidden attribute specified. Yep > > <del>Elements that are not hidden should generally not link to or refer > to elements that are hidden.</del> > <ins> Elements that are not themselves hidden must not hyperlink to > elements that are hidden. Aria-flowto and aria-owns attributes on > elements that are not themselves hidden, similarly, must not reference > hidden elements.</ins> Yep > > For example, it would be incorrect to use the href attribute to link to > a section marked with the hidden attribute. Since the content is not > rendered, linking to it</del> would have unpredictable > behavior</del><ins>would result in behavior the user does not > expect</ins> , either dropping the user at a location with no rendered > content, or failing to navigate. +1 (tired of typing yep...) > > <del>It would similarly be incorrect to use the ARIA aria-flowto or > aria-owns attributes to refer to descriptions that are themselves > hidden, as these elements are not available to the user.</del> > > However, hidden elements may be used to provide descriptive strings, > using aria-describedby and aria-labelledby and the <label> element. > > <p class="note">Any structure in the referenced element, including > headings, links, tables, paragraphs, and form elements, will be lost. > The text children of the element will be flattened to a string. As such, > authors should only use this technique <del>for string content</del> > </ins>where such flattened content will provide a good user > experience</ins>. At the time of this writing, some screen reader > products will read both the accessible name and accessible description, > so authors should take care with the length of text provided via this > method.</p> Yes, these are all more precise wordings, and I have no issue with any of the proposed edits. JF
Received on Friday, 20 April 2012 23:07:07 UTC