Tracking handling of nameless regions and forms #2

xi · 2019-04-16T20:22:10Z

AFAIU, elements with the role region or form are always landmarks and should not be ignored. However, an HTML <form> element only gets the implicit role form if it has an explicit label. Same for <section> and region.

https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings

The text was updated successfully, but these errors were encountered:

matatk · 2019-05-03T19:56:48Z

Ah yes, good spot. There is an explanation of why the Landmarks extension behaves in this way, but on reflection that explanation is mistaken.

The HTML Accessibility API Mapping is clear that both unlabelled <form> and unlabelled <section> (region) elements are not to be counted as landmark regions. This extension discounts any unlabelled element with a role of form or region too, which is in line with most assistive technologies, and is intended to reduce noise in landmark navigation.

Whilst it's true that assistive technologies generally ignore both unlabelled <form> and unlabelled <section> (region) elements for brevity's sake (which also matches the HTML AAM spec), I don't think I had actually established how screen-readers behave when the roles are explicitly specified. As you mention, the spec states that when the role has been explicitly set it should be reflected.

What this issue is saying

In summary... the following are not landmarks:

<form>
<section>

But the following all are landmarks:

<form aria-labelledby="form-header">
<section aria-labelledby="section-header">
<div role="form">
<div role="region">

Testing in the wild

However, I tested it and found some interesting stuff...

Here's the HTML I used...

<!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title>Explicit regions</title>
</head>
<body>
	<h1>Explicit regions</h1>
	<div role="region">
		<p>This should be in a "region" region.</p>
	</div>
	<div role="form">
		<p>This should be in a "form" region.</p>
	</div>
</body>
</html>

Here's what I found...

Browser	JAWS 2019	NVDA 2019.1.1
Firefox 66	No regions found	Doesn't detect the "region" Detects the "form"
Chrome 74	No regions found	Doesn't detect the "region" Detects the "form"
IE 11	No regions found	Doesn't detect the "region" Detects the "form"

Now I think that some of this is because of the same reason that Landmarks initially discounted unlabelled "form" and "region" elements (regardless of how they got their roles)—because things like ASP sites used to surround everything on the page in a <form>, and the idea with empty <section>s was the same. The way that Landmarks currently works is that it only looks at the role an element has now; it doesn't track where it got the role from (implicit or otherwise). I wouldn't be surprised if the assistive technoloiges work the same way (it's simpler after all).

It sounds like the specs are saying that we need to care about where an element got its role, which is interesting (and, again, reflects the practical considerations regarding noise caused by too many landmarks, above).

I think the next bit of testing to do would be to see how the screen-readers fare with unlabelled and labelled <section> and <form> elements (to complete the scenarios listed in the first subsection of this comment, above).

Reference info

We had a bit of a discussion about these in the ARIA/HTML specs a while back; I'll need to refresh my memory, but the most up-to-date locations for those issues appear to be w3c/aria#513 and w3c/core-aam#11

I'll try to do more on this soon, but thought I should reply with what I have for now :-).

xi · 2019-05-03T22:15:57Z

If I understand correctly, my interpretation of the spec is correct, it's just that the spec is far from perfect in this aspect.

Still I would argue that the tests in this repo should reflect the current state of the spec. We can work to improve it separately.

matatk · 2019-05-08T09:31:49Z

Absolutely, I agree—we have to stick to the spec(s) here, even if we decide not to in our own code, at least temporarily. It seems to me that the next steps should be:

More testing, to include the other cases relevant to this issue.
Try to find out if the apparent anomaly between the specs—that whether a landmark is considered a landmark should depend on how it got its role—is intended.
Try to find out if the behaviour of the assistive technologies is intended (particularly with respect to the explicitly-set role attributes).
Add tests for the above to this repo, so that the spec is fully implemented, but add notes to indicate why scanners might not do this.

I’m happy to look into all of the above.

Hopefully, after going through these steps, some consensus will emerge as to whether the spec should change, or the assistive technologies should/will :-).

xi · 2019-05-08T10:02:35Z

Try to find out if the apparent anomaly between the specs—that whether a landmark is considered a landmark should depend on how it got its role—is intended.

That is not my understanding. A form role is always a landmark. But a <form> element does not always have the role "form".

matatk · 2019-05-08T11:40:42Z

A form role is always a landmark. But a <form> element does not always have the role "form".

Ah, yes, of course, that's the correct way to put it (and it sounds simpler that way, too :-)).

I guess the question is: should assistive technologies convey unlabelled form/region landmarks that have been explicitly set by the author (e.g. <div role="region">), or should the main ARIA spec be changed such that these are only considered valid if labelled? Not a question for us to decide, but at least if we know what the question is, we can ask it :-).

It's interesting that NVDA conveys unlabelled "form" regions, but not unlabelled "region" regions—perhaps that's because of experience in the wild; would be good to know.

matatk · 2019-05-17T17:14:22Z

I've been looking at the main ARIA 1.1 spec again and this is what it has to say about the "region" role:

Authors MUST give each element with role region a brief label that describes the purpose of the content in the region. Authors SHOULD reference a visible label with aria-labelledby if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible...

Does the "MUST" at the start mean that <div role="region"> on its own is actually not valid? Or does it mean that the <div> is still to be treated as a landmark, but that the author has committed an error?

It seems the most logical option would be the former, which matches all of the above interpretation of the spec.

With the "form" role it's a bit different—there's no "MUST" regarding the label:

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

This clearly implies that <div role="form"> is valid even without a label, again as above.

(Incidentally, I was thinking about surfacing errors with landmarks to the user in the Landmarks extension.)

xi · 2019-05-17T20:59:15Z

So <div role="region"> is clearly invalid. I could not find anything in ARIA1.1 about how invalid input should be handled. It seems like ignoring the role attribute is the more common option.

matatk · 2019-05-30T10:44:34Z

We got a clear and helpful answer on how this apparent failure should be handled:

This will appear in the Accessibility Tree as role region but with no accessible name. Core-aam specifies how this maps to accessibility APIs at
https://w3c.github.io/core-aam/#details-id-57

The latest (1.2) draft of the ARIA spec has a section called "handling author errors" whic contains a lot of info about this stuff. It doesn't, however, specifcially mention errors where a required label is missing, so we are thinking about making a suggestion on that.

matatk · 2019-06-01T11:55:21Z

In summary...

For forms:

<form> without an accessible name doesn't get a landmark role
<form> with an accessible name gets a "form" landmark role
<div role="form"> gets a "form" landmark role (as the ARIA spec says, a "form" region should be labelled, but it's not mandatory)

For <section>/regions:

<section> without an accessible name doesn't get a landmark role
<section> with an accessible name gets a "region" landmark role
<div role="region"> doesn't get a landmark role (it's ignored as it's an author error—the ARIA spec mandates labels for "region" landmarks)
<div role="region" aria-label="..."> and <div role="region" aria-labelledby="..."> (with valid labels) get a "region" landmark role

The changes to the tests in this repo that are needed are:

A test could be added for <div role="form">—actually there is one in the "roles-land" test, but that is not a very specific test, it's more of an overall example, so maybe a specific test should be added (and maybe even that one should be retired).
A link could be added to the metadata for the "region-alone-is-ignored" test to clarify it.

Overall, though, it looks like the tests are accurate as they are, though making some annotations to the metadata could help improve clarity for the future. Thanks @xi for your help in clarifying this :-).

xi · 2019-06-01T13:21:57Z

<div role="region"> doesn't get a landmark role (it's ignored as it's an author error)

I am a bit confused. the tweet you quoted before said the opposite, right?

Overall, though, it looks like the tests are accurate as they are

Yes, you are right. I had some reason to write this issue, but I don't really remember which test it was. Maybe I just misread something.

However, looking through it again, I think there actually is one mistake: There is a <div role="form"> in the "roles-land" test that is missing in the expectation.

matatk · 2019-06-01T14:24:56Z

I am a bit confused. the tweet you quoted before said the opposite, right?

Having re-read it, I can see that the tweet and the Core AAM don't seem to agree. The Core AAM says that <div role="region"> (i.e. without an accessible name) would not be exposed as a landmark role (at all).

Update: Ah, I understand the apparent discrepancy between the tweet and the Core AAM now: a "region" with no accessible name would still appear in the accessibility tree, but as per the Core AAM, it would take whatever the default role for such a thing is in the host environment; it would not be given a landmark role. (cc @xi)

However, looking through it again, I think there actually is one mistake: There is a <div role="form"> in the "roles-land" test that is missing in the expectation.

Well spotted. I think I should do some more testing to see how screen-readers handle this, but I agree that it should be there, per the spec.

#2 (comment)

With some help :-) I think we've got to the bottom of [how forms and regions, `<form>` and `<section>` should be recognised](#2 (comment)). This also includes some updates to the expectation metadata schema, and hopefully helpful links to give this background info. Further, the schema requires the root of the expectations themselves to be an array. Closes #2.

matatk · 2019-06-03T21:02:49Z

I asked around at work before merging the PR, and we all agreed this interpretation is sound. Thanks @xi (and everyone else who helped). I've just tagged 0.2.1 with this change in it.

* Support aria-roledescription (closes #316) * Fix form labelling requirements in line with recent developments in matatk/page-structural-semantics-scanner-tests#2

carmacleod · 2021-11-19T14:28:29Z

@matatk Making sure you noticed that Core-AAM now says that role=form without accessible name is NOT a landmark.
w3c/core-aam#97

xi · 2021-11-19T14:50:54Z

@carmacleod I may be missing something, but I don't really understand your point. According to WAI-ARIA, landmark is a superclass of the role form. Core-AAM just says how that maps to platform APIs, but it has nothing to do with the question at hand, does it?

carmacleod · 2021-11-19T16:11:19Z

The link you gave is for ARIA 1.1, and it says the following for form:

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

but ARIA 1.2 is moving to Candidate Recommendation as we speak, and the spec for form now says:

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

So, looking at @matatk's #2 (comment) above, the 3rd point is no longer true:

For forms:

<form> without an accessible name doesn't get a landmark role

<form> with an accessible name gets a "form" landmark role

~~<div role="form"> gets a "form" landmark role~~

Instead, the following 4 points are now true:

For forms:

<form> without an accessible name doesn't get a landmark role

<form> with an accessible name gets a "form" landmark role

<div role="form"> without an accessible name doesn't get a landmark role

<div role="form"> with an accessible name gets a "form" landmark role

xi · 2021-11-19T19:07:24Z

Thanks for the clarification. I don't like that role="form" is simply ignored, but at least it is somewhat consistent.

carmacleod · 2021-11-19T19:21:13Z

at least it is somewhat consistent.

Yep. It's consistent with html <form>, and it's also consistent with the way role="region" is mapped.

matatk · 2021-12-05T12:50:10Z

Acronyms are expanded in here to help any casual readers who may stumble across this.

Thanks for the heads up @carmacleod, and for seeking clarification @xi, and sorry for my slow reply.

As you say, this issue will need to be reopened and addressed to match the spec. My first thought, though, is that should be done only when 1.2 reaches W3C Recommendation (REC) stage, as it's not official until then. However, I think you have more experience in standards, and particularly this one, than me, so would be interested as to your thoughts. Sometimes, if all the UAs and AT already support a Candidate Recommendation (CR) I can appreciate it may be appropriate to go with that. Because this is a test suite, though, I feel some significant pressure to stick to the finalised spec—because in theory we're making a decision that will affect downstream projects' support status.

I'll need to do some testing to see how ATs are handling form regions at the moment; my supposition is that they will probably not have changed, and may not for a while, but I'll report back once I've done that testing.

I've been thinking again about how to build a tool above this test suite that can be used to test AT as well as projects like @xi's a11y-outline and the Landmarks extension—and specifically the issue that @xi raised about getting it adopted somewhere (#29; I'm not sure WPT is the right place, as discussed there, but will see if I can talk with more people to gauge where might be a good home—look out for more on that thread when possible, too).

matatk added the bug Something isn't working label Jun 2, 2019

matatk added a commit that referenced this issue Jun 2, 2019

Add tests for explicit "form" roles

9fc2bf4

#2 (comment)

matatk mentioned this issue Jun 2, 2019

fix: Explicit form regions should not be ignored #8

Merged

matatk closed this as completed in #8 Jun 3, 2019

This was referenced Jun 5, 2019

Share code with a11y-outline matatk/landmarks#303

Open

Update README wrt form and region roles #10

Closed

matatk mentioned this issue Sep 1, 2019

feat: Support aria-roledescription (also fix forms detection) matatk/landmarks#317

Merged

matatk reopened this Dec 5, 2021

matatk changed the title ~~region/form without label should not be ignored~~ Tracking handling of nameless regions and forms Dec 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking handling of nameless regions and forms #2

Tracking handling of nameless regions and forms #2

xi commented Apr 16, 2019 •

edited

Loading

matatk commented May 3, 2019

xi commented May 3, 2019

matatk commented May 8, 2019

xi commented May 8, 2019

matatk commented May 8, 2019

matatk commented May 17, 2019

xi commented May 17, 2019

matatk commented May 30, 2019

matatk commented Jun 1, 2019 •

edited

Loading

xi commented Jun 1, 2019

matatk commented Jun 1, 2019 •

edited

Loading

matatk commented Jun 3, 2019

carmacleod commented Nov 19, 2021

xi commented Nov 19, 2021

carmacleod commented Nov 19, 2021

xi commented Nov 19, 2021 •

edited

Loading

carmacleod commented Nov 19, 2021

matatk commented Dec 5, 2021

Tracking handling of nameless regions and forms #2

Tracking handling of nameless regions and forms #2

Comments

xi commented Apr 16, 2019 • edited Loading

matatk commented May 3, 2019

What this issue is saying

Testing in the wild

Reference info

xi commented May 3, 2019

matatk commented May 8, 2019

xi commented May 8, 2019

matatk commented May 8, 2019

matatk commented May 17, 2019

xi commented May 17, 2019

matatk commented May 30, 2019

matatk commented Jun 1, 2019 • edited Loading

xi commented Jun 1, 2019

matatk commented Jun 1, 2019 • edited Loading

matatk commented Jun 3, 2019

carmacleod commented Nov 19, 2021

xi commented Nov 19, 2021

carmacleod commented Nov 19, 2021

xi commented Nov 19, 2021 • edited Loading

carmacleod commented Nov 19, 2021

matatk commented Dec 5, 2021

xi commented Apr 16, 2019 •

edited

Loading

matatk commented Jun 1, 2019 •

edited

Loading

matatk commented Jun 1, 2019 •

edited

Loading

xi commented Nov 19, 2021 •

edited

Loading