- From: Sofia Celic-Li <sofiacelic@gmail.com>
- Date: Tue, 15 Jun 2010 11:33:49 -0700
- To: public-pfwg-comments@w3.org
- Message-ID: <AANLkTil3MvYEe1NP-g8h0pfTpFA1w9Vp7af_K-fGOcKl@mail.gmail.com>
The online form did not allow submission with my email address, so sending this comment to the list. Comment: One of the areas that I have not been able to find a sufficient implementation solution for is labeling of form controls that need to reference external text as well as themselves via the aria-labelledby attribute. That is, the aria-labelledby attribute requires a list of values that reference text external to the form control as well as the form control's own title or aria-label attribute value. While the aria-labelledby attribute is supported in later versions of screen readers such as JAWS, it only works with references to external labels and currently only if the form control does not have a title attribute (or, presumably, an aria-label attribute when this is supported). Attempting to reference the form control's title or aria-label attribute value (via referencing the form control's ID value) is not supported. It would seem that the current hierarchy imposed by the computation rules would not allow such a concatenation of labels. This means that I am back to using hacks that were used pre-ARIA. I am required to either place all of the information in the title attribute value (repeating text that is already present in the page) or I include a hidden version of the form control's original title value (by hiding it off screen). Neither of these should be necessary and ARIA has then failed to improve this implementation issue. Also note that in this scenario a change in design for the general audience is not desirable. Proposed Resolution: I am proposing a slight change in order for the computation rules. The aria-labelledby attribute would be first in the preference hierarchy and allowed to reference its own element (via ID) in order to add a value provided by an attribute lower in the hierarchy - either from aria-label and/or from an appropriate attribute allowed by the technology in use (such as title or alt). Limiting parent attribute referencing to attributes lower in the hierarchy prevents a loop. If the aria-labelledby attribute is missing or empty then use aria-label; and so forth as per the hierarchy outlined in the current draft. The text for 4.6.1.1 part 2A would be: Authors *MAY* specify an element's text alternative in content attributes<http://www.w3.org/TR/2009/WD-wai-aria-implementation-20091215/#def_attribute>, used in this order of preference: - The aria-labelledby attribute, which joins referenced substrings, takes precedence as the element's text alternative. The attribute can reference its parent element in order to add a value provided by an attribute lower in this preference list (this prevents aria-labelledby from referencing itself). The text alternatives for all the elements referenced will be computed using this same set of rules. User agents will then trim whitespace and join the substrings using a single space character. Substrings will be joined in the order specified by the author (IDREF order in the aria-labelledby attribute). - If aria-labelledby is empty or undefined, the aria-label attribute is used. - If aria-labelledby and aria-label are empty or undefined, check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative. For example, in HTML, the img element's alt attribute defines a label string and the label element references the form element it labels. Thank you for taking the time to consider this late submission of feedback. Sofia Celic-Li
Received on Tuesday, 15 June 2010 18:34:25 UTC