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.

Sign up for GitHub

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

Jump to bottom

When is legend label for fieldset? #250

Closed
JAWS-test opened this issue Sep 18, 2019 · 13 comments
Closed

When is legend label for fieldset? #250

JAWS-test opened this issue Sep 18, 2019 · 13 comments

Comments

@JAWS-test
Copy link

JAWS-test commented Sep 18, 2019 •
edited
Loading

For legend is defined:

  • IA2_RELATION_LABEL_FOR with the parent fieldset
  • The LabeledBy property for the parent fieldset points to the UIA element for the legend element.
  • ATK_RELATION_LABEL_FOR with parent fieldset element

I wonder if that's correct, since it doesn't make any statement about what happens
@ZoeBijl
Copy link

ZoeBijl commented Sep 18, 2019 •
edited
Loading

According to the fieldset-element documentation in the spec the name is taken from the first legend child element which also has to be the first child of the fieldset. Meaning that any other result is an author error. So yes, this is correct.

@ZoeBijl ZoeBijl closed this as completed Sep 18, 2019
@ZoeBijl ZoeBijl reopened this Sep 18, 2019
@JAWS-test
Copy link
Author

I thought HTML-AAM should point out here that legend is only label for fieldset if it is the first child element. If it is not the first child element, it is ignored. Analogous to the distinction between header and footer scoped to the body element or not scoped to.

@ZoeBijl
Copy link

ZoeBijl commented Sep 18, 2019

Did you run any tests in which this breaks?

@JAWS-test
Copy link
Author

I'm afraid I don't understand what tests you mean? An empirical test with Screenreader? I'm happy to do that if you wish. But the specification should be correct, regardless of the screenreader output.

@JAWS-test
Copy link
Author

JAWS-test commented Sep 18, 2019 •
edited
Loading

So far I've only tested the following: FreedomScientific/standards-support#233. But that doesn't include the question I raised here. See also: FreedomScientific/standards-support#100

@ZoeBijl
Copy link

ZoeBijl commented Sep 18, 2019

I’m not entirely sure what the error is with HTML-AAM. Could you point to the section in the spec where you saw the error? 5.5.1 fieldset Element Accessible Name Computation reflects the HTML spec. Point four states that if the above conditions are false there is no accessible name.

@JAWS-test
Copy link
Author

I didn't say it was an error. I was just wondering if the documentation should be more accurate:

If this is considered as not problematic, the ticket can be closed. I just thought the table should be as accurate as for header and footer.

@JAWS-test
Copy link
Author

Checked the following file with JAWS 2019 and current Firefox ESR, IE 11, and Chrome:

  • Firefox is halfway ok (browser automatically corrects the display if legend is not the first child)
  • in IE 11 the output is completely wrong
  • in Chrome the output of Tab Navigation seems relatively ok, but if you look into the element overview with INS+Ctrl+E, you can see that everything is wrong here as well
<!DOCTYPE html>
<html lang="en">
	<head>
		<meta charset="utf-8">
		<title>legend</title>
	</head>
	<body>
		<fieldset>
			<div>
				<legend>not a child</legend>
				<input aria-label=1>
			</div>	
		</fieldset>
		<fieldset>
			<input aria-label=2>
			<legend>not first child</legend>
			<input aria-label=3>
		</fieldset>
		<fieldset>
			<legend>1st child</legend>
			<legend>2nd child</legend>
			<input aria-label=4>
			<legend>4th child</legend>
			<input aria-label=5>
		</fieldset>
	</body>
</html>

@JAWS-test JAWS-test mentioned this issue Sep 18, 2019
Open
@scottaohara
Copy link
Member

closing this issue as there's no lack of clarity of how a legend should be mapped (here) or used (via the HTML spec).

That said, I will look into amending my WIP PR #232 to reference "first child" rather than just "child", to better match the HTML spec as per your second bullet in your opening question. Your third bullet in your latest comment isn't accurate, as the fieldset accessible name algorithm does state "...use the subtree of the first such element. " which indicates that legends after the first are ignored because the accessible name for the fieldset has already been determined.

@scottaohara
Copy link
Member

Let's be clear here though, stress testing how a browsers may expose and/or screen reader consumes invalid markup patterns is not indicative of a gap how HTML elements are mapped.

@JAWS-test
Copy link
Author

JAWS-test commented Sep 18, 2019 •
edited
Loading

It's true: The bugs also occur for things that are correctly specified in the specification, see FreedomScientific/standards-support#315.
But if it's not exactly in the specification, you can't blame assistive technology for bugs.

@JAWS-test
Copy link
Author

@scottaohara

Your third bullet in your latest comment isn't accurate, as the fieldset accessible name algorithm does state "...use the subtree of the first such element. " which indicates that legends after the first are ignored because the accessible name for the fieldset has already been determined.

My comment refers as written to https://w3c.github.io/html-aam/#html-element-role-mappings and not to https://w3c.github.io/html-aam/#fieldset-element-accessible-name-computation where it is halfway correct.

And the table says (as described in detail in my very first statement):

For legend is defined:

  • IA2_RELATION_LABEL_FOR with the parent fieldset
  • The LabeledBy property for the parent fieldset points to the UIA element for the legend element.
  • ATK_RELATION_LABEL_FOR with parent fieldset element

@scottaohara
Copy link
Member

scottaohara commented Sep 18, 2019 •
edited
Loading

you can't blame assistive technology for bugs

I didn't. If anything I was saying that invalid markup patterns are to blame.

The bugs also occur for things that are correctly specified in the specification

In that case not related to HTML AAM. Bugs with browsers or AT or both. It's good to try and determine which exactly so issues are filed in the correct place.

My comment refers as written to https://w3c.github.io/html-aam/#html-element-role-mappings and not to https://w3c.github.io/html-aam/#fieldset-element-accessible-name-computation where it is halfway correct.

I know what your comment was referring to, but the opening of that section states:

Where applicable, how an element participates in the computation of its own or another element's accessible name and/or accessible description is described in the Accessible Name and Description Computation section below.

In other words, you have to look to both sections to get the full picture.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@scottaohara @ZoeBijl @JAWS-test