W3C

Site Navigation

Nearby

Results of Questionnaire ISSUE-204: How to exempt ARIA attributes from the rule that prohibits reference to hidden elements? - Straw Poll for Objections

The results of this questionnaire are available to anybody. In addition, answers are sent to the following email addresses: pcotton@microsoft.com, rubys@intertwingly.net, mjs@apple.com, mike@w3.org

This questionnaire was open from 2012-07-26 to 2012-08-03.

5 answers have been received.

Jump to results for question:

  1. Objections to permitting @aria-describedby to point at elements hidden by @hidden.
  2. Objections to change the @hidden section to permit ARIA attributes to reference hidden elements.

1. Objections to permitting @aria-describedby to point at elements hidden by @hidden.

We have a Change Proposal that proposes to allow the ARIA @aria-describedby attribute to point at elements hidden by the @hidden attribute. This proposal says authors 'SHOULD NOT reference hidden content which would lose essential meaning when flattened'. It also differs in wording from the other proposal. See the proposals for details. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to permitting @aria-describedby to point at elements hidden by @hidden.
Simon Myers
Richard Schwerdtfeger I object to this statement:

"Because authors sometimes need to provide a complex description of a page element for users of Assistive Technology without any forced visual encumbrance or default visual indicator, HTML should allow this to be done in the most straightforward manner, by enabling aria-describedby="" to point at elements hidden with the hidden="" attribute. "

Rationale: Although the intent of this proposal is to allow for the common use case for hidden descriptions in ARIA, the use of the word should or the attempt to dictate the authoring practices of another specification leads to a number of very serious issues:

1. The use of the word should vs. must leaves impression of doubt on whether authors should use use aria-describedby to reference hidden content. The ARIA specification does Implementation in Host Languages (http://www.w3.org/WAI/PF/aria/host_languages). Nowhere in here does it state that other specifications can redefine how authors should use ARIA.

2. This provides yet another place where the WAI-ARIA specification team needs to keep track of authoring guidance. We have both an authoring practices guide as well as a user agent implementation guide. The HTML specification must not be dictating the implementation of another spec. by authors or user agents unless agreed upon by members of that working group for this reason.

3. WAI-ARIA is a cross cutting technology. Any restrictions should be addressed in WAI-ARIA so that they may be applied to other host languages.

I object to this text:

"When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user."

For this reasons:

The use of hidden content is indeed directly relevant to the page. The use of aria-describedby to reference hidden content is a very commonly used implementation of ARIA where additional help information is provided to assistive technology vendors without visually impacting the UI. There is extensive implementation of using aria-describedby, by authors and browsers, to reference hidden content in forms to provide help information. Often, hidden information is provided to screen reader users to provide additional keyboard shortcut information that a sighted user may not desire to use as they operate a pointing device. This additional keyboard information may be provided in a Web application's documentation as well, but for a blind user they need help immediately for these short cuts as a productivity measure, yet exposing this information to a sighted user could clutter up the user interface and make it difficult to use.

Furthermore, assistive technologies have the option of not speaking the help information all the time as the user becomes familiar with the application.

The use case for using hidden content to describe HTML elements was first introduced by Freedom Scientific. Customers wanted JAWS to speak additional help information in forms defined by the author and special non-standard attributes were defined to do this in the past. We have incorporated this functionality in WAI-ARIA for this reason.


2. I object to the wording of this statement:

"While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe."

aria-describedby is a global attribute and can be used to describe or provide additional information on ANY HTML element. It is not confined to describing images. This highlights yet another problem with another specification defining how another specification should be used.

This statement is in direct violation of what is intended by the ARIA specification. Furthermore, the ARIA implementation guide clearly states how hidden content is to be mapped to platform accessibility APIs in the cases where content is hidden. In these cases it is mapped to the accessible description (a string of text extracted from the hidden web content).

This guidance is wrong and it gives the impression that authors not following this guidance are doing something wrong - which they are NOT.

As chair of the WAI-ARIA standards effort in PF this guidance also has a direct negative impact on the WAI-ARIA specification to which HTML does not control.

3. I object to this statement:

User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="".

This creates an undue burden on assistive technologies. Assistive technologies, such as screen readers would need to provide navigation of hidden content to make this worth while. This would mean that the AT would have to produce something similar to an accessibility tree or DOM that the browser already does and then walk it. That is a huge burden and we don't want to have ATs start to become browsers. Unless the user agent is going to provide a vehicle to render the hidden content referenced by aria-describedby in the future then the HTML5 specification should not make this statement. We should not be requiring ATs to reproduce the functionality of the browser which includes parsing content into their own DOM. This was done in the past in the early versions of IBM's Home Pager Reader and the fact is that the web is constantly evolving and this model cannot be sustained.

Given the impact on the WAI-ARIA specification and the extensive negative impact on IBM products I will push for a formal objection by IBM of the HTML 5 specification if this change proposal goes through.
Benjamin Hawkes-Lewis + Objection

I object to the proposed text -

“User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="". However, because historically some User Agents have flattened hidden content when exposing such content to Assistive Technology, authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.”

- because it contradicts WAI-ARIA 1.0’s normative requirements for calculating the accessible description for a node in the accessibility hierarchy. These require user agents to expose content referenced by @aria-describedby as *plain text* (i.e. flattened). The text above presents such flattening as an historical implementation detail, rather than a specified requirement.

http://www.w3.org/WAI.new/PF/aria/roles#descriptioncalculation
John Foliot I object to this change proposal, and in particular this section:

"User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby=""."

This can result in harmful behaviors, particularly with regard to tab focus requirements. WCAG 2 mandates that all tab-focus-able elements be visually noted when focus is place on that element. Allowing tab focus (due to full rich semantic exposure) will result in sighted users tabbing to tab-focus-able elements that are out of visual range. (2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible. (Level AA) http://www.w3.org/TR/WCAG/#navigation-mechanisms

Further, for certain structural elements such as tables, the flattening effect that hidden content experiences, renders those tables as completely unusable to non-sighted users, as the inherent X,Y comprehension model of tables will be lost.

I have posted an example page that illustrates these problems at http://john.foliot.ca/html5/w3c/hidden.html
Janina Sajka Additional Comment to John Foliot's Test Page:
The lost focus behavior is particular relevant not to screen reader users, but to sighted users
who read the video display, but whose disabilities prevent them from using a mouse (or other pointing device)--people who use keyboard navigation, e.g. TAB/Shift+TAB to navigate.

2. Objections to change the @hidden section to permit ARIA attributes to reference hidden elements.

We have a Change Proposal that proposes to allow the ARIA @aria-describedby attribute to point at elements hidden by the @hidden attribute. This proposal says authors 'SHOULD avoid using hidden elements for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.)'. It also differs in wording from the other proposal. See the proposals for details. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to change the @hidden section to permit ARIA attributes to reference hidden elements.
Simon Myers I object to adopting this change proposal because of the ‘SHOULD avoid’ clause quoted above: the explanation for it given in the change proposal is because some user agents currently flatten the text, suggesting that this is always unacceptable.

This would be an unnecessary restriction on authors, since it is based purely on a hidden element containing certain other elements, rather than taking the effect of those elements into account. In contrast with the other change proposal (which proposes a restriction on losing essential meaning), this change proposal would restrict certain mark-up even if it loses no meaning at all when flattened, and so causes no disadvantage to anybody at all, even in current user agents.

For example, consider this mark-up — which contains a list, so would be restricted by this change proposal:

<p>My salad yesterday included these ingredients:
<ul>
<li>sausage,
<li>bacon,
<li>black pudding,
<li>tomato,
<li>lettuce,
<li>dressing.
</ul>

When flattened, the text of that mark-up becomes:

My salad yesterday included these ingredients: sausage, bacon, black pudding, tomato, lettuce, dressing.

Flattening the text has not caused any essential meaning (in fact, any meaning at all) to be lost, so nobody is disadvantaged by their software giving them the flattened version. As such, there's no advantage to anybody in an author avoiding using such mark-up, even in a hidden element where it risks being flattened.

The risk of flattened text putting certain users at a disadvantage is adequately covered by the other change proposal, which restricts mark-up which would cause essential meaning to be lost (and only that).

I further object to this change proposal because the restriction it proposes is phrased as “SHOULD avoid”. This is a confusing way of expressing it, since it doesn't use the RFC2119 language used for other restrictions in ‘HTML5’. In particular, it isn't clear whether “should avoid” carries the same meaning as “should not”, or there is some nuance of difference, and such lack of clarity makes interpreting the spec harder for authors and implementers.

And I further object to the definition of structured text being given by example, thereby leaving room for differences of opinion on whether a particular element is structured or not. ‘HTML5’ currently defines terms it uses precisely, explicitly listing members of sets and which elements count as which type of content. If a restriction on elements within hidden elements were to be added to ‘HTML5’ then for it to be unambiguously and interoperably implemented (for example, in validators) then it should be defined with the same rigor.

Finally, I object to the list of example elements using both “eg” and “etc”, since this is nonsensical. If ‘HTML5’ is to place a restriction on certain elements being used in hidden elements, and that restriction is to be defined by example, then the example should make sense. Using either “eg” at the start of a list of actual elements, or a list of actual elements followed by “etc” conveys the meaning that the elements listed are only a subset of those the term applies to. Using “eg” and “etc” together is making the claim that “etc” is an example of structured text, which it isn't. Having nonsense in the spec is an impediment to it being followed by both authors and implementers.
Richard Schwerdtfeger I object to this normative statement residing in the HTML specification. This belongs in the WAI-ARIA specification and it would be a very good issue to address in ARIA 1.1:

"Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements. 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 would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate. "

This is a normative statement in the HTML5 specification for WAI-ARIA. The WAI-ARIA specification should impose this restriction and not the HTML5 specification. WAI-ARIA is a cross-cutting technology and these restrictions should apply anywhere that WAI-ARIA is used, like SVG. I would rather this be opened as an issue for ARIA 1.1 which is designed to address gaps related to HTML5 and they will be picked up in the accessibility work on SVG.
Benjamin Hawkes-Lewis + Objection 1

I object to the proposed text -

“User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-describedby="". However, because historically some User Agents have flattened hidden content when exposing such content to Assistive Technology, authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.”

- because it contradicts WAI-ARIA 1.0’s normative requirements for calculating the accessible description for a node in the accessibility hierarchy. These require user agents to expose content referenced by @aria-describedby as *plain text* (i.e. flattened). The text above presents such flattening as an historical implementation detail, rather than a specified requirement.

http://www.w3.org/WAI.new/PF/aria/roles#descriptioncalculation

+ Objection 2

I object to the text -

“When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive”

- because shifting to a language of relevance to one of visibility incorrectly implies @hidden is presentational and specific to the visual medium. Traditionally, presentational features like "display: none" have been abused to hide irrelevant DOM subtrees from most users. Defining @hidden in terms of relevance gives HTML an unambiguous semantic enabling clear communication from authors to user agents about what parts of the DOM tree are relevant for rendering and interaction.

The rubric "content to be reused by other parts", from first Change Proposal, should be sufficient to overcome concerns that the language of irrelevance implies @hidden descriptions somehow aren't important to assistive technology users.

+ Objection 3

I object to the proposed text -

"Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate."

- since this contradicts the spec elsewhere, which fully defines the result (navigation occurs, but the user agent does not bring the hidden area to the user's attention, for example by scrolling it into view). For a detailed walk-through of the spec on this point, please see:

http://lists.w3.org/Archives/Public/public-html-a11y/2012Apr/0166.html
John Foliot
Janina Sajka Objection: It is inappropriate to base any HTML 5 behavior on the current
ARIA specifications because the current ARIA specifications are normative for HTML 4 only. Work has not yet
begun on ARIA for HTML 5, except as has been negotiated with the PF-WG expressly for use in HTML 5 specifications. If the HTML-WG wishes to negotiate additional ARIA behavior for its HTML 5 specifications, it should propose the particulars to the PF-WG.

More details on responses

  • Simon Myers: last responded on 27, July 2012 at 15:48 (UTC)
  • Richard Schwerdtfeger: last responded on 31, July 2012 at 15:34 (UTC)
  • Benjamin Hawkes-Lewis: last responded on 2, August 2012 at 07:27 (UTC)
  • John Foliot: last responded on 4, August 2012 at 02:15 (UTC)
  • Janina Sajka: last responded on 4, August 2012 at 03:55 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.