Update from PR #1018 for nameFrom: heading #1860

cookiecrook · 2023-01-26T00:58:31Z

Part of #w3c/accname/issues/138

Adds nameFrom: heading (this overcomes PR #1018)

Will update these along the way after further discussion and review.

Related AccName Issue/PR: Add nameFrom: heading steps to computation after spec addition ARIA PR #1860 is reviewed. accname#182
Related APG Issue/PR:

Implementation tracking

validator tests
WPT tests: ARIA WG Agenda+ new namefrom: heading tests for accname web-platform-tests/wpt#44490
Browser implementations (link to issue or when done, link to commit):
Does this need AT implementations? Unlikely. Should be an engine-specific change.

Preview | Diff

Closes #899

index.html

cookiecrook · 2023-01-26T03:06:09Z

Adding three reviewers that were prior contributors to #1018.

scottaohara

just a quick list of the roles that will get name from heading

alertdialog
article
complementary
dialog
form
region (with HTML caveat)

My initial review:

complementary may need a caveat added per the conditional complementary role for the aside element.

similarly, I think form would need a host language caveat mentioned as well, as while I think this update works since ARIA requires role=form have an accName, I don't think every HTML form element should automatically get an accName. That'd have the potential to add extra and unnecessary landmark verbosity to many web pages

should we consider adding group to this as well? Esp. since it's more likely for AT to even expose an element with role=group if it's named. If there's a heading there, it could be done for authors without the need to use aria-labelling. But per my comment above, maybe this would have the inverse impact of creating too much verbosity where things were already "fine" from the user's perspective?

additionally, navigation should be considered for naming by heading. many instances of people using headings (visible or not) to name navigation landmarks via aria-labelledby.

i'm quite a fan of all other aspects of this PR.

cookiecrook · 2023-02-13T23:58:37Z

@scottaohara wrote:

Thanks.

complementary may need a caveat added per the conditional complementary role for the aside element.

To clarify, are you suggesting nameFrom: heading be removed from both <aside> and role="complementary" or only from the contexts where aside is not complementary?

similarly, I think form would need a host language caveat mentioned as well, as while I think this update works since ARIA requires role=form have an accName, I don't think every HTML form element should automatically get an accName. That'd have the potential to add extra and unnecessary landmark verbosity to many web pages

I don't have a strong opinion either way, so I'll remove it in the PR unless there are objections. To clarify, are you suggesting nameFrom: heading be removed from both <form> and role="form" or something else?

should we consider adding group to this as well? Esp. since it's more likely for AT to even expose an element with role=group if it's named. If there's a heading there, it could be done for authors without the need to use aria-labelling. But per my comment above, maybe this would have the inverse impact of creating too much verbosity where things were already "fine" from the user's perspective?

I think group should remain explicitly named, for the verbosity risk you've outlined.... but I could be convinced if you and others have strong opinions for it.

additionally, navigation should be considered for naming by heading. many instances of people using headings (visible or not) to name navigation landmarks via aria-labelledby.

I support this.

jnurthen

common/script/aria.js needs moving to aria-common but otherwise looks good.

I like the scope of the other changes being limited to

alertdialog
article
complementary
dialog
region (with caveats)
as it is now. We can always add more later if folks think that is desired.

scottaohara · 2023-02-14T20:26:32Z

@cookiecrook
Re: complementary and form, yes would need to be clear that while these ARIA roles can get name from heading, the equivalent HTML elements may not (aside) or would not (form) get name from headings.

re: group, agreed. i felt icky suggesting it, and your response didn't wash the ick away. so let's forget it..

cookiecrook · 2023-02-15T07:37:05Z

Re: complementary and form, yes would need to be clear that while these ARIA roles can get name from heading, the equivalent HTML elements may not (aside) or would not (form) get name from headings.

Maybe we should consider taking complementary and region out of the list because of these caveats? We can always add them back in with separate issues.

Especially since we're now working on automated AccName tests...

scottaohara · 2023-02-15T12:37:14Z

sounds like a good idea to me.

…cussion, these will be taken up as separate issues

cookiecrook · 2023-02-16T08:49:37Z

Recycling reviews because I think this addresses all the feedback now.

Affected roles now limited to the following for this PR.

alertdialog
article
dialog

Others that are no longer in this diff, but should be taken as separate PRs due to editorial and host language caveats are:

complementary
region

Also @jnurthen I have filed the script changes as w3c/aria-common#89 I wasn't sure how to mark that PR as blocking this one. FYI @scottaohara

index.html

@scottaohara

Good catch by @scottaohara in review Co-authored-by: Scott O'Hara <[email protected]>

benbeaudry · 2023-06-01T22:25:52Z

@cookiecrook This change is a step in the right direction in my opinion. I don't have any issues with it. Merge it, and we'll build it in Chromium eventually!

pkra · 2023-06-02T06:06:40Z

@spectranaut @jnurthen perhaps we should have labels for the new process requirements, e.g., something for each step in https://github.com/w3c/aria/blob/main/documentation/process.md#normative-changes).

Then PRs / features like this could also easily be looked up.

index.html

cookiecrook · 2023-01-26T02:48:49Z

common/script/aria.js

      var fromContent = '';
-      var fromEncapsulation = '';
-      var fromLegend = '';


FYI, the script diff looks jumbled below, but it's just that I removed the stale encapsulation and legend blocks, and added nameFrom heading before contents and prohibited. Although I did not touch contents and prohibited, the GitHub diff viewer is intertwining those sections with the removed encapsulation and legend sections.

cookiecrook · 2023-01-26T02:56:56Z

index.html

-                </div>
+			<section id="namefromauthor">
+				<h4>Roles Supporting Name from Author</h4>
+				<div id="index_fromauthor"></div>


Yes, this is whitespace correction, which I would normally be opposed to in a substantive diff, but the spaces vs tab inconsistency was in a section that I had to modify anyway. I claim editorial discretion.

cookiecrook · 2023-01-26T03:01:58Z

index.html

@@ -3018,7 +3036,6 @@ <h2>Definition of Roles</h2>
 			<div class="role-description">
 				<p>A dialog is a descendant window of the primary window of a web application. For <abbr title="Hypertext Markup Language">HTML</abbr> pages, the primary application window is the entire web document, i.e., the <code>body</code> element.</p>
 				<p>Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. See related <rref>alertdialog</rref>.</p>
-				<p>Authors MUST provide an accessible name for a dialog, which can be done with the <pref>aria-label</pref> or <pref>aria-labelledby</pref> attribute.</p>


Note: This is an editorial removal. Not substantive.

Accessible Name Required is defined as True below, so this normative requirement remains. I'm removing excessive duplication that will be resolved in the AccName spec with w3c/accname/issues/182.

cookiecrook · 2023-01-26T03:04:01Z

index.html

@@ -6802,7 +6824,7 @@ <h5>Presentational Role Inheritance</h5>
 			<div class="role-description">
 				<p>A <rref>landmark</rref> containing content that is relevant to a specific, author-specified  purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.</p>
 				<p>Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other <a href="#landmark_roles">landmark roles</a>, such as <rref>main</rref>, <rref>complementary</rref>, or <rref>navigation</rref>.</p>
-				<p>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 <pref>aria-labelledby</pref> if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role <rref>heading</rref>.</p>
+				<p>Authors MUST give each element with a region role a brief label that describes the purpose of the region. For host languages that support elements with the default role of region (e.g., HTML <code>section</code>), authors would need to specify an explicit <code>role="region"</code> on the element to enable the nameFrom: heading technique.</p>


Note: This diff was originally authored by Jon Gunderson in #1018 and further edited by @scottaohara.

index.html

cookiecrook · 2023-05-09T18:17:55Z

index.html

@@ -3554,7 +3571,6 @@ <h2>Definition of Roles</h2>
 			<div class="role-description">
 				<p>A <rref>landmark</rref> region that contains a collection of items and objects that, as a whole, combine to create a form. See related <rref>search</rref>.</p>
 				<p>A form can contain a mix of host language form controls, scripted controls, and hyperlinks. Authors are reminded to use native host language semantics to create form controls whenever possible. If the purpose of a form is to submit search criteria, authors SHOULD use the <rref>search</rref> role instead of the generic <code>form</code> role.</p>
-				<p>Authors MUST give each element with role <code>form</code> a brief label that describes the purpose of the form. Authors SHOULD reference a visible label with <pref>aria-labelledby</pref> if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role <rref>heading</rref>.</p>


Note: This is an editorial removal. Not substantive.

Accessible Name Required is defined as True below, so this normative requirement remains. I'm removing excessive duplication that will be resolved in the AccName spec with w3c/accname#182.

cookiecrook · 2023-05-09T18:18:02Z

index.html

@@ -6879,7 +6895,6 @@ <h5>Presentational Role Inheritance</h5>
 			<div class="role-description">
 				<p>A <rref>landmark</rref> containing content that is relevant to a specific, author-specified  purpose and sufficiently important that users will likely want to be able to navigate to the section easily and to have it listed in a summary of the page. Such a page summary could be generated dynamically by a user agent or assistive technology.</p>
 				<p>Authors SHOULD limit use of the region role to sections containing content with a purpose that is not accurately described by one of the other <a href="#landmark_roles">landmark roles</a>, such as <rref>main</rref>, <rref>complementary</rref>, or <rref>navigation</rref>.</p>
-				<p>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 <pref>aria-labelledby</pref> if a visible label is present. Authors SHOULD include the label inside of a heading whenever possible. The heading MAY be an instance of the standard host language heading element or an instance of an element with role <rref>heading</rref>.</p>


Note: This is an editorial removal. Not substantive.

Accessible Name Required is defined as True below, so this normative requirement remains. I'm removing excessive duplication that will be resolved in the AccName spec with w3c/accname#182.

index.html

spectranaut · 2023-12-12T01:08:44Z

I added the "waiting for implementations" tag but I was wrong, this isn't ready for implementation -- I didn't look close enough. This change still needs the following before it can be implemented:

three approving reviews
accname changes
tests

This new process is a work in progress, so let me know if there are questions/concerns!

jcsteh · 2023-12-12T04:43:39Z

My only concern here is performance. The content of container elements like these can be potentially massive, and because of potential mutations, it's not even as simple as just caching the first heading when we build the tree. Is it reasonable for UAs to impose some limit on how many nodes we check? If so, I wonder if that needs to be specified somehow?

cookiecrook · 2024-02-01T18:57:57Z

@jcsteh wrote:

Is it reasonable for UAs to impose some limit on how many nodes we check?

Certainly possible, but where to draw the line? Some web dev will hit an arbitrary depth limit. Do we tie it to DOM or rendering heuristics? My original issue was intended to allow some spec permissiveness so that implementations could account for this as best they could, which may eventually inform a best path forward... AS of now, some of those heuristics are explicitly disallowed by the spec.

What modification do you propose?

index.html

closes #457 Related to the following: - w3c/aria#1860 - w3c/accname#229 (this needs to be merged so the new links to 'accName: name from heading' will work

closes #457 Related to the following: - #1860 - w3c/accname#229 (this needs to be merged so the new links to 'accName: name from heading' will work

aleventhal · 2024-07-09T20:15:09Z

I'm no longer blocking this, so @jnurthen you're up next and then this can finally land.

aleventhal · 2024-07-09T20:16:22Z

Ah, this is "waiting for implementations", which means we should land the changes in Blink and not wait for it to be merged into the spec, right?

Update the from PR #1018 for nameFrom: heading

b6131e5

Closes #899

cookiecrook mentioned this pull request Jan 26, 2023

Issue899 accname from heading #1018

Closed

cookiecrook linked an issue Jan 26, 2023 that may be closed by this pull request

ARIA Spec could be more flexible when elements with "nameFrom:author" are left unlabeled by the author w3c/accname#138

Open

cookiecrook mentioned this pull request Jan 26, 2023

Readme should document expectations of for New PR template and New Issue template (order, optionality, etc.) #1861

Closed

cookiecrook requested review from accdc and scottaohara January 26, 2023 01:51

cookiecrook mentioned this pull request Jan 26, 2023

Add nameFrom: heading steps to computation after spec addition ARIA PR #1860 is reviewed. w3c/accname#182

Open

cookiecrook commented Jan 26, 2023

View reviewed changes

index.html Outdated Show resolved Hide resolved

cookiecrook and others added 2 commits January 25, 2023 18:38

m. specref reconciliation.

de9cfa8

ReSpec script, too

d11b6a4

cookiecrook requested a review from jnurthen January 26, 2023 03:04

scottaohara mentioned this pull request Jan 26, 2023

Update: Elements which will receive proposed name from heading w3c/html-aam#457

Open

scottaohara reviewed Jan 26, 2023

View reviewed changes

jnurthen previously requested changes Feb 14, 2023

View reviewed changes

revert changes to aria.js as these will come from the aria-common repo

3192676

cookiecrook added a commit to w3c/aria-common that referenced this pull request Feb 16, 2023

namefrom-heading script additions blocking w3c/aria#1860

504ff11

pull namefrom:heading for complementary and region; due to review dis…

b4f7124

…cussion, these will be taken up as separate issues

cookiecrook mentioned this pull request Feb 16, 2023

namefrom-heading script additions w3c/aria-common#89

Merged

cookiecrook requested review from jnurthen and scottaohara February 16, 2023 08:49

scottaohara reviewed Feb 16, 2023

View reviewed changes

index.html Outdated Show resolved Hide resolved

scottaohara reviewed Feb 16, 2023

View reviewed changes

index.html Outdated Show resolved Hide resolved

Missed removing one ref to region

3370b0b

Good catch by @scottaohara in review Co-authored-by: Scott O'Hara <[email protected]>

cookiecrook requested a review from scottaohara February 16, 2023 23:36

spectranaut added the waiting for implementations Cannot be merged until there are two browser impls or one impl + impl commit label Jun 20, 2023

spectranaut removed the Agenda label Jun 27, 2023

pkra added this to the ARIA 1.3 milestone Jun 28, 2023

aleventhal reviewed Jul 20, 2023

View reviewed changes

index.html Outdated Show resolved Hide resolved

cookiecrook commented Aug 17, 2023

View reviewed changes

cookiecrook added the Agenda label Oct 5, 2023

cookiecrook mentioned this pull request Oct 5, 2023

Requesting changes to new implementation-blocked merging process #2055

Closed

cookiecrook mentioned this pull request Oct 16, 2023

Ambiguous cascade of role invalidation rules (including dependency label computation) complicates implementations #2064

Open

spectranaut removed the Agenda label Nov 28, 2023

spectranaut removed the waiting for implementations Cannot be merged until there are two browser impls or one impl + impl commit label Dec 12, 2023

cookiecrook mentioned this pull request Feb 1, 2024

Links that include header elements omit their descendant content from the link's accessible name w3c/accname#226

Open

accdc approved these changes Feb 1, 2024

View reviewed changes

Clarify that DFS is referring to IDDFS

42e33c3

cookiecrook commented Feb 3, 2024

View reviewed changes

index.html Outdated Show resolved Hide resolved

cookiecrook mentioned this pull request Feb 3, 2024

Add nameFrom: heading to AccName text alt algorithm w3c/accname#229

Closed

scottaohara added a commit to w3c/html-aam that referenced this pull request Feb 6, 2024

Addition: Name from heading

55d748e

closes #457 Related to the following: - w3c/aria#1860 - w3c/accname#229 (this needs to be merged so the new links to 'accName: name from heading' will work

scottaohara mentioned this pull request Feb 6, 2024

Addition: Name from heading w3c/html-aam#529

Closed

1 task

Moving the more technical part of the definition to the AccName PR.

ade3a8e

jnurthen added the waiting for implementations Cannot be merged until there are two browser impls or one impl + impl commit label Apr 16, 2024

pkra pushed a commit that referenced this pull request May 23, 2024

Addition: Name from heading

8433264

closes #457 Related to the following: - #1860 - w3c/accname#229 (this needs to be merged so the new links to 'accName: name from heading' will work

pkra added the spec:aria label Jun 14, 2024

aleventhal approved these changes Jul 9, 2024

View reviewed changes

spectranaut mentioned this pull request Aug 13, 2024

[html-aam PR 529] Addition: Name from heading #2215

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update from PR #1018 for nameFrom: heading #1860

Update from PR #1018 for nameFrom: heading #1860

cookiecrook commented Jan 26, 2023 •

edited by pr-preview bot

Loading

cookiecrook commented Jan 26, 2023

scottaohara left a comment

cookiecrook commented Feb 13, 2023 •

edited

Loading

jnurthen left a comment

scottaohara commented Feb 14, 2023

cookiecrook commented Feb 15, 2023 •

edited

Loading

scottaohara commented Feb 15, 2023

cookiecrook commented Feb 16, 2023

benbeaudry commented Jun 1, 2023

pkra commented Jun 2, 2023

cookiecrook Jan 26, 2023

cookiecrook Jan 26, 2023

cookiecrook Jan 26, 2023

cookiecrook Jan 26, 2023

cookiecrook May 9, 2023

cookiecrook May 9, 2023

spectranaut commented Dec 12, 2023

jcsteh commented Dec 12, 2023

cookiecrook commented Feb 1, 2024

aleventhal commented Jul 9, 2024

aleventhal commented Jul 9, 2024 •

edited

Loading

Update from PR #1018 for nameFrom: heading #1860

Are you sure you want to change the base?

Update from PR #1018 for nameFrom: heading #1860

Conversation

cookiecrook commented Jan 26, 2023 • edited by pr-preview bot Loading

Implementation tracking

cookiecrook commented Jan 26, 2023

scottaohara left a comment

Choose a reason for hiding this comment

cookiecrook commented Feb 13, 2023 • edited Loading

jnurthen left a comment

Choose a reason for hiding this comment

scottaohara commented Feb 14, 2023

cookiecrook commented Feb 15, 2023 • edited Loading

scottaohara commented Feb 15, 2023

cookiecrook commented Feb 16, 2023

benbeaudry commented Jun 1, 2023

pkra commented Jun 2, 2023

cookiecrook Jan 26, 2023

Choose a reason for hiding this comment

cookiecrook Jan 26, 2023

Choose a reason for hiding this comment

cookiecrook Jan 26, 2023

Choose a reason for hiding this comment

cookiecrook Jan 26, 2023

Choose a reason for hiding this comment

cookiecrook May 9, 2023

Choose a reason for hiding this comment

cookiecrook May 9, 2023

Choose a reason for hiding this comment

spectranaut commented Dec 12, 2023

jcsteh commented Dec 12, 2023

cookiecrook commented Feb 1, 2024

aleventhal commented Jul 9, 2024

aleventhal commented Jul 9, 2024 • edited Loading

cookiecrook commented Jan 26, 2023 •

edited by pr-preview bot

Loading

cookiecrook commented Feb 13, 2023 •

edited

Loading

cookiecrook commented Feb 15, 2023 •

edited

Loading

aleventhal commented Jul 9, 2024 •

edited

Loading