You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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").
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
The text was updated successfully, but these errors were encountered:
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):
Furthermore, the definition of "prohibited" states: (marking in bold-italic relevant sentences for the purpose of this clarification):
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:
which has been replaced in the draft version (https://w3c.github.io/accname/#mapping_additional_nd_name) with (marking in bold-italic differences)
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
The text was updated successfully, but these errors were encountered: