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

CORE-AAM: Add conditional platform mappings for nameless forms #514

Closed
matatk opened this Issue Jan 24, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@matatk

matatk commented Jan 24, 2017

This is a spin-off from #513 which resolves that region landmarks should only be considered as such if they are named (via aria-labelledby or aria-label).

Background: I have been researching how screen-readers expose landmarks to users, because I work on a WebExtension that does the same. This issue has been filed as a spin-off from issues filed in other W3C specs (linked below).

This issue proposes that the same approach be applied to form regions, for the reasons mentioned in that thread, and in the related HTML-AAM issue #82 but repeated here for convenience:

  1. There are instances in the wild of <form> elements wrapping whole pages [1,2,3] - these are not really valid landmarks, so considering them as such would add noise and confusion.
  2. When a <form> is 'genuine': if it lacks a label, there's not really any useful landmark information there (it's easy enough to navigate to the form/first form control for most users anyway), so adding all unlabelled forms would add too much noise to the landmark navigation.

Related issues:

@joanmarie joanmarie self-assigned this Aug 2, 2017

@joanmarie joanmarie changed the title from CORE-AAM 1.1: Add conditional platform mappings for nameless forms to CORE-AAM: Add conditional platform mappings for nameless forms Sep 13, 2017

@joanmarie

This comment has been minimized.

Show comment
Hide comment
@joanmarie

joanmarie Sep 13, 2017

Contributor

I don't think we can address this strictly through the Core AAM. The Core AAM states how to expose things from the ARIA spec via platform accessibility APIs. Taking the region role as an example, here's what ARIA 1.1 says:

Authors MUST give each element with role region a brief label that describes the purpose of the content in the region.

In other words, it is author error to use the region role without an accessible name. It just shouldn't happen. But what should user agents expose via platform accessibility APIs in the case of such an author error? That's where the Core AAM comes in.

But things are slightly different for the form role. Again, looking at what ARIA 1.1 says:

Authors SHOULD provide a visible label for the form referenced with aria-labelledby.

It does not say they have to. And the short definition of form in the ARIA 1.1 spec is:

A landmark region that contains a collection of items and objects that, as a whole, combine to create a form.

Nowhere in the ARIA 1.1 spec does it suggest that authors who fail to name their form-role elements are in error or doing anything which will turn those elements into non-landmarks. But if we change the platform mappings for nameless forms as suggested in the opening report, assistive technologies will not include the form in the list of landmarks, and might not even know the author used the form role, instead presenting it to users as if it was just another roleless div element. This assistive technology behavior might not be what the author, who followed the stated requirements of the ARIA spec, expects....

For this reason, I think we need to reach consensus on whether we want to change the ARIA spec to make naming forms an author MUST. If we do, and once that change is in the ARIA spec, then we can state in the Core AAM what user agents need to do when the author fails to name their forms. Because ARIA 1.1 is in CR already, this will need to wait until ARIA 1.2 I'm afraid.

Contributor

joanmarie commented Sep 13, 2017

I don't think we can address this strictly through the Core AAM. The Core AAM states how to expose things from the ARIA spec via platform accessibility APIs. Taking the region role as an example, here's what ARIA 1.1 says:

Authors MUST give each element with role region a brief label that describes the purpose of the content in the region.

In other words, it is author error to use the region role without an accessible name. It just shouldn't happen. But what should user agents expose via platform accessibility APIs in the case of such an author error? That's where the Core AAM comes in.

But things are slightly different for the form role. Again, looking at what ARIA 1.1 says:

Authors SHOULD provide a visible label for the form referenced with aria-labelledby.

It does not say they have to. And the short definition of form in the ARIA 1.1 spec is:

A landmark region that contains a collection of items and objects that, as a whole, combine to create a form.

Nowhere in the ARIA 1.1 spec does it suggest that authors who fail to name their form-role elements are in error or doing anything which will turn those elements into non-landmarks. But if we change the platform mappings for nameless forms as suggested in the opening report, assistive technologies will not include the form in the list of landmarks, and might not even know the author used the form role, instead presenting it to users as if it was just another roleless div element. This assistive technology behavior might not be what the author, who followed the stated requirements of the ARIA spec, expects....

For this reason, I think we need to reach consensus on whether we want to change the ARIA spec to make naming forms an author MUST. If we do, and once that change is in the ARIA spec, then we can state in the Core AAM what user agents need to do when the author fails to name their forms. Because ARIA 1.1 is in CR already, this will need to wait until ARIA 1.2 I'm afraid.

@joanmarie joanmarie added the blocked label Sep 13, 2017

@matatk

This comment has been minimized.

Show comment
Hide comment
@matatk

matatk Sep 14, 2017

@joanmarie thanks for your reply. Is this issue thread the correct forum for the discussion that you mention we need to have for 1.2? (I'm keen to contribute to this, as I'd say that, for reasons 1 and 2 above—and that the ATs I've used ignore unlabelled <form>s—this change ought to be made.)

I imagine the best time to bump this will be a short while after 1.1 is published; please could you let me know if here, or somewhere else, is the best place to discuss it? Thanks :-).

matatk commented Sep 14, 2017

@joanmarie thanks for your reply. Is this issue thread the correct forum for the discussion that you mention we need to have for 1.2? (I'm keen to contribute to this, as I'd say that, for reasons 1 and 2 above—and that the ATs I've used ignore unlabelled <form>s—this change ought to be made.)

I imagine the best time to bump this will be a short while after 1.1 is published; please could you let me know if here, or somewhere else, is the best place to discuss it? Thanks :-).

@joanmarie

This comment has been minimized.

Show comment
Hide comment
@joanmarie

joanmarie Sep 14, 2017

Contributor

@matatk: This is the best place. Should that change, I'll update this issue with the new best place. 😄 And thank you for your interest and help with this matter!

Contributor

joanmarie commented Sep 14, 2017

@matatk: This is the best place. Should that change, I'll update this issue with the new best place. 😄 And thank you for your interest and help with this matter!

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

jnurthen May 21, 2018

Contributor

This issue was moved to w3c/core-aam#11

Contributor

jnurthen commented May 21, 2018

This issue was moved to w3c/core-aam#11

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment