Allow array/object binding for all (or specific a11y related) attributes

What problem does this feature solve?

The docs state that we have special functionality when v-bind is used with class and style. These are really useful because class and style are often references to other things. That exact use-case applies to a lot of attributes that are involved in semantic and accessible markup.

For instance, the aria-describedby attribute which accepts a list of IDs and must have correct spacing to be compatible with all screenreaders; this list is often dynamic and often controlled externally so we would potentially need to combined local describedby with some coming in externally.

Doing

:aria-describedby="trim(`${describedBy} ${componentId}-affix`)"

works, but if describedBy is a Boolean it would have to be evaluated separately to avoid printing ‘false’. Essentially we have to rebuild whatever beautiful easiness the Vue engine already does for class and style in order to make sure our code is semantic.

Attributes that would greatly benefit from this would be most aria relationship attributes as well as non-aria relationship type attributes like the headers attribute on a table cell.

return ['error', 'hint']
        .filter(prop => this[prop])
        .map(prop => `${this.componentId}-${prop}`)
        .join(' ').trim();

I have been doing a lot of weird code to get proper strings based on the values of nested data and realized this exact logic is already hidden somewhere in Vue.js. I think writing accessible code is extremely important and Vue should make it as simple as possible to do so. This (and perhaps a community standard way to set predictible IDs automatically) would make establishing semantic relationships between elements/components (the main accessibility challenge with dynamic js driven interfaces that are so popular these days) much simpler.

Being able to update the docs to call out these important attributes would be a great opportunity to push people toward writing more accessible code as well.

What does the proposed API look like?

:aria-describedby="[describedBy, `${componentId}-affix`]"

Not sure if there are specific issues with just allowing any attribute to behave this way, but that would be my preferred solution. If that is too difficult or causes particular performance concerns then adding that behaviour to specific attributes (those called out above, but I would have to review all valid html attributes to see which would make sense) would be a good alternative solution.

[Justineo]

I think users would implement the same logic in their application layer anyway (repeating those Vue has done for class). We may need this feature for those attributes which accept space-separated tokens. It requires Vue to maintain a list for this, but for aria-* attributes I think the tradeoff is worth considering.

There’s still one problem that when users asks why inheritAttrs doesn’t work for class and style, we did claim that we have special treatment for them so they are not passed into $attrs when inheritAttrs: false. If we do the same for aria-* attributes that logic might be not accurate anymore.

[BonnieCabrera]

why does not have chinese doc?