w3c
Nooby question: Form field value or form field name?
I was wondering if someone could help me understand the following test case:
if given
<h2 id="test">
Country of origin:
<input role="combobox" type="text" title="Choose your country." value="United States">
</h2>
then the accessible name of the element with id of "test" is "Country of origin: United States"
Why in this example, would the value attribute be used rather than the title? It seems to me that in step 2D, the title is selected therefore step 2E is never reached. It certainly seems like I'm missing something, but I can't find what it might be.
@WilcoFiers I have previously argued (see #10 ) that 2D needs changing so that title is not mentioned as in HTML IMO it is not an "attribute that defines a text alternative" IMO title should not take any part in the accname algorithm until you get to 2I "Otherwise, if the current node has a Tooltip attribute, return its value."
The 1.0 Rec stated the following for the equivalent of 2D (in 2A bullet 3) "If aria-labelledby and aria-label are both empty or undefined, and if the element is not marked as presentational (role="presentation"), check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative. For example, in HTML, the img element's alt attribute defines a label string and the label element references the form element it labels. See How to Specify Alternate Text ([HTML], section 13.8) and HTML 5 Requirements for providing text to act as an alternative for images ([HTML5], section 4.8.1.1)."
and then in 2I equivalent (which confusingly was 2D) "The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results."
How this first one got changed to how it is currently written such that it sounds like title should be involved is the source of all of these problems and needs to be resolved.
...as a lurker on this list...
+1 to James.
JF
On Tue, Oct 9, 2018 at 6:01 PM, James Nurthen [email protected] wrote:
@WilcoFiers https://github.com/WilcoFiers I have previously argued (see #10 https://github.com/w3c/accname/issues/10 ) that 2D needs changing so that title is not mentioned as in HTML IMO it is not an "attribute that defines a text alternative" IMO title should not take any part in the accname algorithm until you get to 2I "Otherwise, if the current node has a Tooltip attribute, return its value."
The 1.0 Rec stated the following for the equivalent of 2D (in 2A bullet 3) "If aria-labelledby and aria-label are both empty or undefined, and if the element is not marked as presentational (role="presentation"), check for the presence of an equivalent host language attribute or element for associating a label, and use those mechanisms to determine a text alternative. For example, in HTML, the img element's alt attribute defines a label string and the label element references the form element it labels. See How to Specify Alternate Text ([HTML], section 13.8) and HTML 5 Requirements for providing text to act as an alternative for images ([HTML5], section 4.8.1.1)."
and then in 2I equivalent (which confusingly was 2D) "The last resort is to use text from a tooltip attribute (such as the title attribute in HTML). This is used only if nothing else, including subtree content, has provided results."
How this first one got changed to how it is currently written such that it sounds like title should be involved is the source of all of these problems and needs to be resolved.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/accname/issues/32#issuecomment-428382105, or mute the thread https://github.com/notifications/unsubscribe-auth/ABK-c53dgDarftxGwcpDHLvBWtVwtO1Zks5ujSrOgaJpZM4XUPlq .
-- John Foliot | Principal Accessibility Strategist Deque Systems - Accessibility for Good deque.com
Regarding the history, here's the commit where the change was made (happened back when all the specs were in a single repo): https://github.com/w3c/aria/commit/dc7cf538.
If you look at what is in the HTML-AAM, you will see many instances where title is stated as the thing to use. Mind you, you'll see in some cases in the HTML-AAM where value is to be preferred before title, and other cases where value is not in the list of sources.
@jnurthen I see what you mean, that would make sense. What I think might be missing though is that even if you get to step 2i, you'll need to ignore title on elements with role=presentation / none. That makes sense, but it might be good to have that be explicit.
I would agree that HTML-AAM could be a bit clearer too.
@joanmarie
If you look at what is in the HTML-AAM, you will see many instances where title is stated as the thing to use.
The AAM documents what is in browsers (mostly), but in particular when it comes to the use of the title attribute. The title attribute has and is used as a fallback accessible name when, in general, no other source exists, otherwise it is used as an accessible description. The HTML-AMM did not define implementations, it was defined by existing implementations. It describes how browsers implement, or it did at the time when i tested and wrote the steps, I am sure that there have been some chnages since then and also in some cases what I documented is not quite correct. issues and PRs welcome :-)
@stevefaulkner: AAMs are the specs that user agents use to implement support for platforms. I get that history might have once dictated otherwise, but they should not be descriptive; they should be prescriptive. Otherwise, the implementation for a given platform winds up being a "do whatever the first guy did." And the first guy might have gotten things wrong because they didn't ask the appropriate people what the right/expected thing should be.
I am not an author, so I lack the expertise about what an author thinks/assumes screen reader should present as the name when $COMPLICATED_EXAMPLE gets focus. That said, as a screen reader developer, I can tell you that the screen reader generally presents the calculated name that was handed to it by the user agent. And the user agent, theoretically, is figuring out what to hand the screen reader based on the AAM governing the feature in question.
Based on this (and other) discussions, I think it might behoove us to figure out what screen readers SHOULD be presenting given $EXAMPLE and ensure that that calculation is what's in the AAM so that it is what user agents give the screen reader.
Hi, I'm not sure what the relevance of role=presentation/none is within this case or how this is supposed to change the naming computation.
For example, here is the modified code with the role changed to presentation.
<h2 id="test">
Country of origin:
<input role="presentation" type="text" title="Choose your country." value="United States">
</h2>
In this case too, the accName is "Country of origin: United States".
The reason for this is that determining whether or not an element is presentational, it must first pass specific criteria. The presence of role=presentation or role=none isn't enough by itself to do this.
For example, for an element to be presentational, it must (1) have either the role of 'presentation' or 'none', (2) it must not be focusable (whether natively or by the inclusion of a tabindex attribute, even if set to '-1' which is also considered focusable within the browser), and (3) it must not include any global ARIA attributes (such as aria-labelledby, aria-label, aria-describedby, etc.).
So, technically, the above construct is invalid because the role="presentation" is invalid because this is a form field that is natively focusable and thus cannot be presentational. For this reason, the same algorithm applies where the value of the form field is used as part of the accessible name when computing child form field (widget) elements.
If I've missed something here, please let me know.
