Other elements which may need special description computation conditions?

[scottaohara]

The accessible description computation section indicates that a table's caption, a summary element's subtree, or the value attribute of an input type=submit|button|reset can all be used as an accessible description if the elements in question have an overriding accName (e.g., aria-label).

While out of scope for resolving w3c/accname#69 and the companion HTML AAM PRs, I have been wondering why these elements are treated as special cases where other similar elements are not?

for instance, why doesn't button element's subtree become also become its accessible description if a stronger naming mechanism is used? Similarly, a table's caption becomes the accDescription if a table has an aria-label... but a fieldset's legend doesn't presently become the description if the fieldset has been given an aria-label.

It seems to me that either we need to expand this behavior to other similar elements, or these special cases shouldn't be there?

If expanding to other elements, then the following would need to be considered for addition to the special cases:

• a element
• button element
• fieldset > legend
• form control with associated label element
• option element with a label attribute or child text

[JAWS-test]

Or there is a reason why the visible label can become the description and why this is only true for a few elements - and this reason is explained

[scottaohara]

From the wg call today, we see three options to go forward here:

1. introduce a new property to the characteristics table where the elements that currently have these special description steps, and potentially others, could instead be exposed under this new property. This would remove the content from being exposed as a description, but still make it available for AT if they chose to expose it.
2. deprecate these special cases because they seem rather arbitrary in comparison to other similar elements which do not share this behavior. There was enough talk on the call today about how extending this behavior to other elements could pose problematic due to common practices of using aria-label to overwrite a name to either purposefully shorten or clarify it, because you specifically do not want the visible text exposed - so making it a description would be unwanted. e.g., 'read more' links.
3. Simply add a note to the spec saying the particular elements with these special cases work this way for historical reasons, and we don't want to remove this functionality in places where it might be relied upon (would love to know of those use cases), but otherwise do not plan to match this behavior on other element, and likely not future elements

[JAWS-test]

I like 2, unless there are a sufficient number of sites that rely on this mechanism (but I don't know of any) - then I would prefer 3