Concatenate non identical sources for ACCNAME and AccDescription Computation about accname HOT 8 OPEN

@devarshipant
That's right... I think @accdc was just restating the proposal, not the current status.

from accname.

moved to AAC Calculation spec
#14

from accname.

@DavidMacDonald ok, now I'm confused. You moved this from the ARIA issues (good and thank you). But you closed this one?

from accname.

ooops, had two windows open.... closed the wrong one.

from accname.

• if an html label and an aria-labelledby are used, they will be concatenated in the accname if they are not identical.
• If an aria-error-message and aria-describedby are on a field they will both be concatenated in the accdescription
• if a title attribute offers more information and there is already an accdescription then it will be concatenated if it is not identical.

I see the need for clarifying what to do with title + aria-describedby and possibly aria-errormessage if no other property is meant for this in the mappings, but I think we will be opening a huge can of worms with aria-label and aria-labelledby because this will change everything about how the computation is calculated. It seems like combining title + aria-describedby is a simple positive change, but the label ones I think are going to need a lot more support by browser implementors to consider because this will change everything that they currently have under the hood.

from accname.

Title is like a fallback in the calculation: only use if there is nothing better, where there is an assumption that accessibility specific attributes are meant for assistive technologies and elements like title are aimed at mouse users.

In practice, user agents will not be able to avoid creating huge amounts of redundancy and extra verbage for screen readers just with a simple string compare. I think we could create a huge problem of tons of unwanted and super annoying speech if we were to concatenate. It could be dreadful. I do not support automatic concatenation.

That said, I too do not like the idea of lost information. So, if the title attribute is not easily accessible by AT as a separate entity,, then perhaps we should fix that problem so that AT users always have an easy way to get to the title. We have a tooltip role, but perhaps we should have a tooltip property that is mapped to the title string.

from accname.

if an html label and an aria-labelledby are used, they will be concatenated in the accname if they are not identical.

Correct me -- I think if label and aria-labelledby are present on a control, aria-labelledby wins.

Here is a test page.

from accname.

Hi,
Just to revisit this since a lot of time has passed and we've discussed this at various times in the WG and have reached what seems to be an agreement about how the mappings should treat this for now.

I wanted to map these things out with a very basic overview.

The algorithms are actually the same between aria-labelledby and aria-describedby, both follow the same mechanism for concatenating multiple ID references and apply the same calculations when parsing embedded content.

The only difference here is which property is being written to. E.G The accessible name is processed and saved as the Name property, then the description is processed and saved in the Description property.

The aria-describedby attribute is always used in reference to setting the Description property, and never applies to setting the Name property.

However, the title attribute applies to both of these properties, with the following exceptions.

1. When there is no Name, as previously set with a valid naming mechanism, then the title attribute is set as the Name property when present, and no Description property is set.
2. When a valid Name is already set however, then the title attribute is set as the Description property instead.
3. When aria-describedby is set, then the referenced computation, if it is not null and does not include only white space characters, is set as the Description property; regardless what the title attribute contains.
4. If, after both the accessible Name and Description properties are computed, and if both Name and Description include the same exact value, then both should be merged into the Name alone to prevent redundant duplication by assistive technologies.

This is a very high level summary of what we've discussed. Many of these processes are already covered by the current algorithm, and others will need to be clarified further. This is meant just to illustrate the core relationship between the Name and Description properties, and how they sometimes appear to overlap when applied to the root node (the primary element being processed for its accessible Name and Description).

Does this make sense? Please let me know if I'm missing anything.

from accname.