Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarification about prohibited acc name and title attribute #1981

Open
giacomo-petri opened this issue Jul 13, 2023 · 3 comments
Open

Clarification about prohibited acc name and title attribute #1981

giacomo-petri opened this issue Jul 13, 2023 · 3 comments
Assignees
Milestone

Comments

@giacomo-petri
Copy link
Contributor

While examining the section on roles that cannot be named (Section 5.2.8.6 https://w3c.github.io/aria/#namefromprohibited), I pondered the following question: "What about attributes that were not intended by the author to serve as names but are utilized by the browser (due to accessibility name computation) as fallback options?"

In Section 5.2.8 on Accessible Name Calculation (https://w3c.github.io/aria/#namecalculation), the definition of "author" (point 1) states (marking in bold-italic relevant sentences for the purpose of this clarification):

author: name comes from values provided by the author in explicit markup features such as the aria-label attribute, the aria-labelledby attribute, or the host language labeling mechanism, such as the alt or title attributes in HTML, with HTML title attribute having the lowest precedence for specifying a text alternative.

Furthermore, the definition of "prohibited" states: (marking in bold-italic relevant sentences for the purpose of this clarification):

prohibited: the element does not support name from author. Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element.

Considering that point 1 includes the host language labeling mechanism, such as the title attribute in HTML, in the "name from author" concept, can we conclude that using the title attribute on a role that cannot be named would violate the requirements where the name from the author is prohibited (e.g., <div role="code" title="example of code">code snippet</div>), even though the "prohibited" point explicitly states that "Authors MUST NOT use the aria-label or aria-labelledby attributes to name the element"?
Or does setting a title attribute on a role that cannot be named (which nonetheless results in a node with an accessible name in many browsers) absolve the author of any failure or responsibility as the intent of the author was not to provide an acc name?


Moreover, although this is not directly related, I noticed while reviewing this topic that the current Accessible Name and Description Computation 1.2 document (https://www.w3.org/TR/accname-1.2/#mapping_additional_nd_name) contains the following statement:

D. Otherwise, if the current node's native markup provides an attribute (e.g. title) or element (e.g. HTML label) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

which has been replaced in the draft version (https://w3c.github.io/accname/#mapping_additional_nd_name) with (marking in bold-italic differences)

E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

Is there a specific reason why the title attribute has been replaced with the alt attribute? Does this change aim to exclude the title attribute from the accessibility name computation?
If this is not the intent and the title attribute should still be used as fallback while computing the acc name, considering that the title attribute generally provides a description or instructions for the element rather than a text alternative, could this present a challenge in terms of setting accurate expectations when reading this decisional/computational tree?

Thanks

@spectranaut
Copy link
Contributor

@scottaohara at the last meeting you said you would look into this, does this still need to be on the agenda? minutes: https://www.w3.org/2023/07/13-aria-minutes#t01

@scottaohara
Copy link
Member

we triaged it last week and put it on the agenda so we could talk about it with more people.

@spectranaut
Copy link
Contributor

Discussed in today's ARIA working group: https://www.w3.org/2023/07/20-aria-minutes.html#t04

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants