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

update / expand input value mappings #396

Open
wants to merge 3 commits into
base: gh-pages
Choose a base branch
from
Open

Conversation

scottaohara
Copy link
Member

@scottaohara scottaohara commented Apr 15, 2022

This PR closes #314 and clarifies the value attribute mappings for other input types.
note: the value attribute only represents the initial value for the input elements that expose the attribute's value. If a user updates a form control the value attribute's value does not mutate to reflect the updated entry. The updates I provided for these inputs attempts to specifically call this out. if this is not clear, please suggest alternate wording.

Note that the input type=color value is far more complex than the other inputs and I would appreciate specific feedback on what would need to be updated here, if anything.

Additionally, the input type=color seems to make a strong case for allowing aria-valuetext on a button element – where the button should be named via a label or an aria-label/labelledby, but still needs to expose it's displayed value (subtree of the button element).

NOTE: due to the still broken table/details/summary script with respec, to view the updated table in the preview, you can add this style via devtools:

#html-attribute-state-and-property-mappings .table-container {
  display: block !important;
}

or find the .table-container that has the display: none on it, and turn that off.

fun...


Preview | Diff

This PR closes #314 and clarifies the `value` attribute mappings for other input types.
note: the `value` attribute only represents *the initial value* for the input elements that expose the attribute's value.  If a user updates a form control the `value` attribute's value does not mutate to reflect the updated entry.  The updates I provided for these inputs attempts to specifically call this out.  if this is not clear, please suggest alternate wording.

Note that the `input type=color` `value` is far more complex than the other inputs and I would appreciate specific feedback on what would need to be updated here, if anything.

Additionally, the `input type=color` seems to make a strong case for allowing `aria-valuetext` on a `button` element – where the button should be named via a `label` or an `aria-label/labelledby`, but still needs to expose it's displayed value (subtree of the button element).
Copy link
Contributor

@spectranaut spectranaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still trying to catch up and get all the context for this change, i have a few questions to start!

index.html Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
<td class="atk">See comments</td>
<td class="ax">See comments</td>
<td class="comments">
If specified, expose the value of the attribute as the initial value entry of the `input` element.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically, what is the "value entry of the input element"?

Do we have the following specified somewhere: if, in one of these inputs, a user has entered text, how that text surfaced in the different accessibility APIs? If so we should link to it if not we should add it?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed, let's use the same language here as in the HTML spec: https://html.spec.whatwg.org/multipage/input.html#attr-input-value

which I think would be (but check my work):

If specified, expose the content value attribute as the default value entry of the `input` element.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not say what these mappings are though? Do we know how the accessibility API for the different platforms surface the value of a input [type="email"] etc? Like AXValue for Mac?

<td class="ax">Use WAI-ARIA mapping</td>
<td class="comments">
<p>
If specified, expose the value of the attribute as the initial value of the `input`. User Agents MUST expose the modified value of the input to the <a class="termref">accessibility tree</a>. User Agents MAY expose the initial or modified value as a human readable text alternative. E.g., `#ff0000` as a localized text alternative of "Red".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these user agents MUSTs apply to the other inputs as well?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing, I think we agreed that "If specified, expose the value of the attribute as the initial value of the input. User Agents MUST expose the modified value of the input to the accessibility tree." belongs in it's own section about all inputs that have attributes (like value or checked) who's default value is set by the content attribute. See the spec: https://html.spec.whatwg.org/multipage/input.html#attr-input-value

This can happen here or in a follow up.

Copy link
Contributor

@spectranaut spectranaut left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From our conversation!

<td class="atk">See comments</td>
<td class="ax">See comments</td>
<td class="comments">
If specified, expose the value of the attribute as the initial value entry of the `input` element.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we discussed, let's use the same language here as in the HTML spec: https://html.spec.whatwg.org/multipage/input.html#attr-input-value

which I think would be (but check my work):

If specified, expose the content value attribute as the default value entry of the `input` element.

<td class="ax">Use WAI-ARIA mapping</td>
<td class="comments">
<p>
If specified, expose the value of the attribute as the initial value of the `input`. User Agents MUST expose the modified value of the input to the <a class="termref">accessibility tree</a>. User Agents MAY expose the initial or modified value as a human readable text alternative. E.g., `#ff0000` as a localized text alternative of "Red".
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing, I think we agreed that "If specified, expose the value of the attribute as the initial value of the input. User Agents MUST expose the modified value of the input to the accessibility tree." belongs in it's own section about all inputs that have attributes (like value or checked) who's default value is set by the content attribute. See the spec: https://html.spec.whatwg.org/multipage/input.html#attr-input-value

This can happen here or in a follow up.

<td class="atk">See comments</td>
<td class="ax">See comments</td>
<td class="comments">
If specified, expose the value of the attribute as the initial value entry of the `input` element.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not say what these mappings are though? Do we know how the accessibility API for the different platforms surface the value of a input [type="email"] etc? Like AXValue for Mac?

Comment on lines +5365 to +5366
Either contributes to the <a data-cite="accname-1.2/#dfn-accessible-name">accessible name</a>, the
<a data-cite="accname-1.2/#dfn-accessible-description">accessible description</a>, or is not mapped (see comments).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Editorial: I think this is phrased ambiguously:

Intention: "either it's:

  • mapped (to name or description) or
  • not mapped."

As phrased with the 3-part serial comma: "either it's mapped to:

  • name,
  • description, or
  • not mapped" (seems like ~"mapped to not mapped")

Copy link
Collaborator

@cookiecrook cookiecrook Apr 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Substantive: I think there are scenarios where implementations may still wish to map it even if it's not used by name or description. Leaving that follow-on mapping optional before the final "is not mapped."

For example, I think once aria-description is implemented, browsers would still want to expose the title here as AXHelp in AX API.

<button aria-label="foo" aria-description="bar" title="bop">bif</button>

@pkra pkra mentioned this pull request May 28, 2024
21 tasks
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

Successfully merging this pull request may close these issues.

value should map to aria-valuenow for input[type=range]
3 participants