- From: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Date: Sat, 21 Apr 2012 13:13:18 +0100
- To: John Foliot <john@foliot.ca>
- Cc: Cynthia Shelly <cyns@microsoft.com>, 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>
On Sat, Apr 21, 2012 at 6:07 AM, John Foliot <john@foliot.ca> wrote: > Benjamin Hawkes-Lewis wrote: > > 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. > >> This still introduces a self-contradiction into the specifications, >> since the behavior is defined to navigate the user to a location with >> rendered content. There's no "or" and both your alternatives are >> wrong. > > "Defined" where? Ben can you supply relevant references when you make these statements please. For ease of comprehension, direct quotes are also appreciated, with the reference URL then provided. Don't make us go hunting to find where you are reading (or misreading) these assertions. I did provide these links to the relevant specifications in this thread: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#scroll-to-fragid http://dev.w3.org/csswg/cssom-view/#element-scrolling-members Consider the markup: <div id="hidden-fragment" hidden>I am hidden.</div> … then a few screens down in the same document … <a href="#hidden-fragment">Link</a> A user clicks on the link. What happens? The UA must follow the hyperlink: http://dev.w3.org/html5/spec/the-a-element.html#the-a-element To follow the hyperlink, the UA must resolve the URL (successfully) then navigate to the URL: http://dev.w3.org/html5/spec/links.html#following-hyperlinks Since the URL is just a fragment identifier relative to the current address, the UA must navigate to the fragment identifier: http://dev.w3.org/html5/spec/history.html#navigate To navigate to the fragment identifier, the UA must add the new URL to navigation history then scroll to the fragment identifier: http://dev.w3.org/html5/spec/history.html#scroll-to-fragid "When the user agent is required to scroll to the fragment identifier, it must either change the scrolling position of the document using the scroll an element into view algorithm defined in the CSSOM View specification, with the align to top flag set, or perform some other action, such that the indicated part of the document is brought to the user's attention. If there is no indicated part, or if the indicated part is not being rendered, then the user agent must not scroll anywhere." In the case of a @hidden fragment, the "indicated part is not being rendered", so the UA does not scroll or otherwise bring the indicated fragment to the user's attention. The proposed text is wrong, because what happens is fully defined: navigation occurs, the address changes, but the UA does not bring the indicated fragment to the user's attention because it is not rendered, so the point of regard remains at the same rendered content as before. Have I missed something here? >> > <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> >> >> Where's the rationale for introducing such text under @hidden rather >> than in the ARIA specification or the WAI-ARIA section of the HTML5 >> spec? > > One rationale is that it is common practice throughout the HTML5 draft spec to provide warnings, advisories or "Notes" - in line - that provides relevant and pertinent advice to content creators (who may or may not go look in other documents). My point is that this note (at least as written) is not especially pertinent to @hidden. ARIA currently says (normatively): "The element or elements referenced by the aria-describedby comprise the entire description." http://www.w3.org/WAI/PF/aria/complete#aria-describedby (ARIA both normatively suggests referenced elements *are* the description and informatively suggests authors use @aria-describedby to reference a hyperlink to a description, which is a self-contradiction.) It also says (normatively) UAs expose "Long description" as the "accessible description" for the chart: http://www.w3.org/WAI/PF/aria/complete#textalternativecomputation It also describes (informatively) how UAs should expose the accessible description in some accessibility APIs as a plain text property and how they should expose pointers between the accessibility tree objects representing the describing elements in a APIs that support such pointers: http://www.w3.org/WAI.new/PF/aria-implementation/#mapping_state-property_table ARIA doesn't currently include a way to establish pointers to descriptions without a plain text accessible description. Consider the following markup: <img alt="October Sales chart" aria-describedby="#description-link"> <a id="#description" href="october-sales.html">Details</a> "Details" is a passable accessible name for the link but it is not a good accessible description for the image. So what can we do? One option is to change user agent requirements. For example, we could map this so that when @aria-describedby points to elements with sub-elements or interactive content, user agents do not expose an accessible description but only expose a pointer to the accesssible element and/or (for APIs that don't support pointers) an accessible action to bring the description into focus. Another option is to add author conformance requirements or guidance. Saying "authors should only use this technique where such flattened content will provide a good user experience" constitutes such guidance, but it is not limited to @hidden. It is undeniable that this markup is even more problematic: <img alt="October Sales chart" aria-describedby="#description"> <a hidden id="#description" href="october-sales.html">Details</a> But it is more problematic *not* because the accessible description is flattened to "Details" (that happens regardless of @hidden) but because user agents will not to expose a pointer to the link because it is not in the accessible object hierarchy. The proposed text fails to express this. Now we could provide text expressing this, but is that useful? Don't we want to be providing guidance/requirements to inhibit authors creating harmful markup like the first example, rather than an even more harmful subset of such markup? And doesn't that generic guidance belong either in the WAI-ARIA section or in WAI-ARIA itself (even if we repeat it in the HTML spec)? >> Saying "The text children of the element will be flattened to a >> string" is a direct contradiction of the ARIA specification which >> takes account of various elements and attributes in the calculation of >> the accessible name and description. > > Again Ben, can you please supply relevant references when you make these statements. Sure. "Text children of the element" means text child nodes (attributes are not "children", child elements are not "text children"). But the algorithm in the ARIA specification recurses over descendant element nodes, attribute nodes, and text nodes. http://www.w3.org/WAI/PF/aria/roles#namecalculation Consider this markup: <div id="label">bar <span> foo </span> <img alt="baz" src="kitten.jpg"> quux</div> The CP spec text implies that the accessible name calculated from the <div> is "bar quux". The ARIA spec text implies that the accessible name calculated from the <div> is "bar foo baz quux". I don't have a strong feeling about including guidance for authors "who may or may not go look in other documents". But the inclusion of guidance that misrepresents the technical references it purports to summarize through vague language (as opposed to explicit wilful violation) is counter-productive. Spec writers can avoid the cost of formulating and maintaining appropriate language by keeping duplication of material in "other documents" to a minimum. For example, we could say something like "accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure". >> Markup is a "string" so "string" is the wrong word to use here: >> >> http://en.wikipedia.org/wiki/String_(computer_science) > > While this very much feels like a splitting of hairs, if you have a better definition / description of what we are talking about here, please be kind enough to provide that change. A criticism without an alternative is simply a waste of everyone's time (IMO) - and this is a time sensitive undertaking. The spec uses some precise definitions of "string" that do not mean "absence of markup". For example, the "innerHTML" property returns a string. I suggest "plain text" or "plain text string". This would be more consistent with language in the spec and its references, for example: http://www.w3.org/TR/charmod/#sec-RefProcModel http://www.rfc-editor.org/rfc/rfc2046.txt http://www.w3.org/WAI/PF/aria/complete#def_accessible_name http://www.w3.org/TR/WCAG/#namedef > Do you have a reason why it shouldn't be "should"? Considering making new guidance MUST-level conformance requirements before reverting to making them SHOULD-level or purely informative leads to thinking through situations that would constitute exceptions to the guidance which helps us produce more precise requirements for interoperability and avoidance of harm. Can we think of any exceptions where using @aria-describedby to reference hidden DOM constituting a good description as rich text but a poor description as plain text would not be harmful? If not, why leave such markup as conforming HTML? If there are such exceptions, it could help authors to spell them out. -- Benjamin Hawkes-Lewis
Received on Saturday, 21 April 2012 12:14:11 UTC