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

Define "scoped" or reuse another existing term? #375

Open
scottaohara opened this issue Mar 10, 2022 · 13 comments · May be fixed by #484
Open

Define "scoped" or reuse another existing term? #375

scottaohara opened this issue Mar 10, 2022 · 13 comments · May be fixed by #484

Comments

@scottaohara
Copy link
Member

This is follow on work to #350 as HTML AAM (and ARIA in HTML) use the term 'scoped' to indicate when a header, footer and aside have an implicit ARIA landmark role, or not. "Scoped" in this context essentially means that they are an ancestor of the body element (or the body or main element, in aside's case), with no intervening sectioning content or sectioning root elements.

There are a few things that need to be addressed with this term:

  1. it is not formally defined as a term at this point. This can be done, but as there are similar concepts in ARIA (required context role / Owned Element) and in HTML (Contexts in which this element can be used), figured it would make sense to get the WG's opinion on if a term name change might be in order. I don't presently think we can just use one of these other terms... but open to being told otherwise - there might be overlap with Update required owned elements and required context role aria#1454
  2. The current wording for scoped elements doesn't take into account what should happen if someone were to specify an intervening element (div) - which is fine for the scoping rule, but gives it an explicit ARIA role which effectively exposes it as an element which should break the scoping rule.
  3. I think this concept is important to specify beyond its current use for header, footer and aside. There are other elements that have similar behavior of becoming 'generic' or having their role 'ignored' under certain circumstances. But as far as i can tell, this isn't actually specified so much as it just is accepted behavior. e.g., a list item is not exposed as a list item if not contained within a list. Or if a table's implicit role is overwritten, all its direct table descendants become generics... and if you say use a td outside of the context of a table, browsers don't even render the element - its contents are just rendered instead.

Interested in people's thoughts on this.
@scottaohara
Copy link
Member Author

scoped defined in css - https://drafts.csswg.org/css-contain-2/#property-scoped

@spectranaut
Copy link
Contributor

The CL for the changes to aside (#350) on Chromium hasn't landed yet, and the question of scope has been brought up!

So here is a question 4: does "scoped to" role obey aria-owns?

In the CL, we did implement question 2 above, which is to say an aria role (like role="blockquote") can make a div into a "scope breaking element". Similarly, role="generic" can turn a <blockquote> into a NOT "scope breaking element". That is how I originally understood "scope" to mean, because of the examples you left on the original chromium issue. Do you think that is now being called into question, or are you saying we just need to make sure to define scope (or whatever other word) to include the ARIA overrides?

@scottaohara
Copy link
Member Author

hi @spectranaut

that's a good catch and yes, we did talk about if someone had an element like blockquote, but then gave it a role=none, that then the ancestor aside could then still map to complementary.

e.g.,

<body>
...
<blockquote>
  <aside>wouldn't map to complementary</aside>
</blockquote>
<blockquote role=none>
  <aside> would map to complementary </aside>
</blockquote>
</body>

If an aside were aria-owned by another element, then as that essentially makes it behave as if it was a descendant of that element, then ideally its role would be exposed in the manner of if it were a true child of that element.

I have no idea how often people are actually doing that, especially since aria-owns is still not supported with webkit. but... meh.

I'll be sure to include this use case. thank you

@spectranaut
Copy link
Contributor

Ok @scottaohara we are still working getting this idea of "scoped" implemented in Chrome. I checked the status of this for all browsers, using "header" as an example, on a Mac. Unfortunately all implementations use only the pre-aria html tree for calculation the role of the header element in all cases:

  • Respects ARIA tree: <article aria-owns="owned-header"></article><header id="owned-header"></header>)

    • Blink: no, header is considered landmark in article
    • Webkit: no, aria-owns not supported
    • Firefox: no, header is considered landmark in article

  • Respects ARIA role generic overrides: <article role="generic"><header></header></article>

    • Blink: no, header is considered generic
    • Webkit: no, header is considered generic
    • Firefox: no, header is considered generic

  • Respects ARIA role article overrides: <div role="article"><header></header></div>

    • Blink: no, header is considered landmark
    • Webkit: no, header is considered landmark
    • Firefox: no, header is considered landmark

@scottaohara
Copy link
Member Author

Yes that is not surprising as previously this had been only implemented based entirely on the html element and did not consider if the role was modified to something else

@spectranaut
Copy link
Contributor

Hey @scottaohara another few question on scope and aria overrides

  1. sectioning root includes td elements. There is a test that looks like this in chromium:
<table role="none">
  <tr>
    <td>
      <header>This should NOT have banner role.</header>
    </td>
  </tr>
</table>

In this case, the header is in a td (sectioning root), but in the accessibility tree the table doesn't exist and td is not mapped to cell. So I'd guess the test above is in incorrect, and that the header in this case would remain a landmark.

  1. Similarly, fieldset as a sectioning root is also a bit confusing, because html-aam maps fieldset to group. So in a way, if we are considering just the accessibility tree, fieldset doesn't exist.

The algorithm in chromium COULD check the dom and always check for the td tag and fieldset tag, as special cases, but that feels like a hack and I'm not sure it's what it is intended.

@scottaohara
Copy link
Member Author

so we should definitely sync up on this because while I can give you answers to your questions, there is also the effort in the HTML spec to revise/remove aspects of the outline algorithm that actually removes the concept of sectioning roots from the HTML spec.

If you have any time over the next few days this week, we could try to talk this out again and see what might need changing per the updates going on in HTML?

@spectranaut
Copy link
Contributor

spectranaut commented Apr 27, 2022 •
edited
Loading

From our conversation, it seems that there is no need to actually use "sectioning roots" other than body to know whether or not an element should be considered a landmark, which simplifies things! Should I wait to make the change the the chromium implementation until you have a spec change here?

For those reading this: the reason is that the best practices for an html document is to have all content in a landmark. It seems weird to prohibit a landmark in a "sectioning root" when the "sectioning root" element should already be contained within "sectioning content" element anyway.

@scottaohara
Copy link
Member Author

and for further clarity here, sectioning roots are identified as the following elements:
blockquote, body, details, dialog, fieldset, figure, td.

with the exception of dialog, all of these elements - if following html/accessibility best practices, would likely be found within a main, article, section or other identified element that would already sever the 'scoped' relationship to negate landmark role. dialog is a weird one... where generally i would balk at the idea of needing landmarks within a dialog.... except for the mega-dialogs i've encountered which are really just mini-web pages smashed into a dialog container, and where landmarks are ridiculous, but potentially useful.

@spectranaut i'd make the change now. I'll get a PR setup for the sectioning root removal from where it's mentioned in the spec.

@spectranaut
Copy link
Contributor

ping @scottaohara I wouldn't mind that PR because I don't want to change my <aside> PR on chromium until I see that change landing here :)

@scottaohara
Copy link
Member Author

sorry, need to get some blocked off time to work on this again.

@SaraSoueidan
Copy link

"Scoped" in this context essentially means that they are an ancestor of the body element

Hey @scottaohara ^^

Just a heads up that there might be a typo in this sentence. Did you mean a descendant (or direct child) of the body element?

@scottaohara scottaohara mentioned this issue Jul 6, 2022
Open
@spectranaut
Copy link
Contributor

Hey @scottaohara maybe I can take this one off your plate and give it a try?

@spectranaut spectranaut mentioned this issue Jan 24, 2023
Merged
@scottaohara scottaohara mentioned this issue Feb 9, 2023
Open
scottaohara added a commit that referenced this issue May 11, 2023
@scottaohara
contextual role concept proposal
c8435a9 
closes #375

The purpose of this proposal is both to resolve the issue that "scoped" was an undefined term that was used to indicate when certain elements would expose particular ARIA roles or not.  However, in the year of noodling on this, other activities to revise what "owned" means in ARIA, the idea of a minimum role, as well as the fact there were other elements in HTML that have "scoped" or "contextual roles" that are based on heuristics, rather than defined standards, became relevant.

A change to hopefully help simplify the implementations of contextual roles is that this proposal is aiming to tie the role of an element based on its a11y tree ancestry, rather than based on specific HTML elements in the DOM.

This PR represents the initial draft of the proposal.  Other work to explicitly call out the elements that have contextual roles, what roles they need to adjust to, and other wording revisions to replace "scoped" with the new term would still need to be made.
@scottaohara scottaohara linked a pull request May 11, 2023 that will close this issue
Draft
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

Successfully merging a pull request may close this issue.

contextual role concept proposal w3c/html-aam
3 participants
@spectranaut @SaraSoueidan @scottaohara