labelledBy/describedBy seems bonkers

[domenic]

In particular, setting an AccessibleNode's labelledBy or describedBy attributes will have no effect on its accessible name or description. Set the label and description attributes directly if you want those to change.

Why even include these attributes then? At the very least make them not settable.

[cookiecrook]

This comment is taken out of appropriate context. If the label is explicitly set, these other attributes are irrelevant. Otherwise they mirror the content attr on real DOM nodes, but would need to be settable attrs on virtual nodes.

[minorninth]

The HTML label element and aria-labelledby are both great high-level abstractions that work well most of the time.

When they break, though, it can be frustrating for developers. Right now if you associate a label element with a control, there are at least three side effects:

1. Clicking on the label is interpreted as clicking on the control
2. The control's accessible name is set to the text of the label
3. An accessible relationship is set up between the label and the control, which enables assistive technology to do things like highlight the label visually when the control has focus

The problem is, what if that isn't what you want? What if you want #1 and #3, but you don't want #2 because the label is an icon and the control needs accessible text?

The idea was to decouple these concepts and let the author set the accessible label of a control independently from establishing that relationship between an object and the object that labels it.

[domenic]

This comment is taken out of appropriate context. If the label is explicitly set, these other attributes are irrelevant. Otherwise they mirror the content attr on real DOM nodes, but would need to be settable attrs on virtual nodes.

I don't quite understand. In addition to the sentence I quoted, the preceding paragraph states that these attributes are "informational only". I can also find no normative description of how they impact the processing model. It seems pretty clear these attributes do nothing, per spec.

The problem is, what if that isn't what you want? What if you want #1 and #3, but you don't want #2 because the label is an icon and the control needs accessible text?

These seem like good goals. In particular, I get the impression that these attributes were meant to help accomplish #3, or maybe #2. But per the spec as it stands, they do nothing, and so do not help with these goals.

[minorninth]

What I think isn't clear is that virtually all of these accessibility attributes get communicated directly to the assistive technology. What it chooses to do with that is up to it. The browser doesn't "do" anything else with this information other than communicate it.

I'll try to clarify that and give some examples of the types of things assistive technologies might do with these relationships. In some cases we should be able to refer directly to the ARIA spec, but in the case of aria-labelledby it might be less clear and perhaps we should clarify it.

[domenic]

I think it's important to normatively state that these are delivered to the accessibility technology, then, and to remove all indications in the spec that these are non-normative or don't affect the processing model.