Skip to content

Way of providing accessible name/description as an HTML element #7326

Closed
Closed
Way of providing accessible name/description as an HTML element#7326
Labels
a11y-trackerGroup bringing to attention of a11y, or tracked by the a11y Group but not needing response.accessibilityAffects accessibility

Description

@domenic
domenic
opened on Nov 10, 2021

Spinning off from some discussion early in #5811, and also relevant to some of the comments on sectioning content vs. not in #7320. /cc @whatwg/a11y

My understanding of the problem: several "section-ish" HTML elements, like section, article, aside, nav, dialog, and #7320's search, get their accessible name or description via this algorithm, which requires either using aria-describedby=""/aria-label=""/aria-labelledby="" attributes, or the HTML title="" attribute.

In general, we want to encourage people to write accessible HTML without needing to rely on ARIA, and would like to co-evolve HTML in a way to improve the situation.

title="" as the current non-ARIA way of providing such accessible names or descriptions is not great, for a couple of reasons:

  • In many browsers, it will cause a tooltip to pop up on mouse hover. It's possible (perhaps likely) that a web developer might want a specific tooltip, but would not want to use the contents of the tooltip as an accessible name/description. Conversely, it's possible (perhaps likely) that a web developer might want a given accessible name/description, but not to cause a tooltip with that value.

  • It only accepts strings, not HTML. This means it loses important capabilities like supscripts/superscripts, ruby, language and directionality markup, etc. /cc @whatwg/i18n who have brought up this sort of thing a good deal in the past.

This issue is about whether we should consider adding new HTML element(s), or repurposing existing HTML element(s), to help with such accessible name/description computation.

Foundational questions I have about this project:

  • Is my understanding of the problem statement accurate?
  • How much of a problem is this, in practice? Are accessible names/descriptions for these "section-ish" HTML elements something that authors should generally provide, or are they only in the accessible name/description computation algorithm for exceptional circumstances?
  • Do these considerations apply equally to all the elements I listed (section, article, aside, nav, dialog, and search)? Are there others I missed?
  • How does accessible name/description interact with the <hN> elements? My vague understanding is that the hNs only contribute to heading-based navigation in most accessibility tech; I can't find any evidence in HTML-AAM or elsewhere that they interact with accessible name/description computation. Is that separation good, or bad? Naively I'd imagine that if you do <section><h3>Section title</h3>...</section>, "Section title" would make a pretty good accessible name...

Some more-detailed questions that might guide a possible proposal; probably not worth answering until we get the above straightened out:

  • Do we want to provide methods for setting both the accessible description and accessible name, or just one?
  • Relatedly, the HTML-AAM algorithm for processing title="" first tries to use it as accessible name, then falls back to using it as the accessible description if an aria-label=""/aria-labelledby="" attribute "claimed" the accessible name value. Is that the kind of semantic we might want here, i.e. this new element is name-first but can be used as a description if ARIA claimed the name? It seems a bit strange, but maybe it works out in practice...
  • Should <hN> elements be involved at all? E.g. maybe <hN name> instead of a new element?
  • If we reuse an existing element, there are lots of candidates: <legend>, <summary>, <caption>; perhaps even <title> or <label>, although probably not. We should probably figure out why in the past we introduced new elements for <summary> and <figcaption> instead of reusing <legend> or <caption>, as that might give us some guidance on the general principles of reuse vs. new element(s).

Activity

  1. domenic
    added
    accessibilityAffects accessibility
    a11y-trackerGroup bringing to attention of a11y, or tracked by the a11y Group but not needing response.
    on Nov 10, 2021

  2. jnurthen commented on Nov 10, 2021

    @jnurthen
    jnurthen
    on Nov 10, 2021
    Member

    You may find some useful information in w3c/aria#1018
    Will comment more later but wanted to add this here now.

  3. scottaohara commented on Nov 10, 2021

    @scottaohara
    scottaohara
    on Nov 10, 2021
    Contributor

    Thanks for opening this, @domenic. @carmacleod had raised an issue about this last year (specifically for landmarks).

    To sort of quickly go over some of your points:

    • I believe you do have a good understanding of the problem - naming HTML elements which have implicit ARIA roles that allow for naming from author presently requires authors use ARIA, or the title attribute (though as I mentioned in the other thread, title may not always work - though that is / was a bug. I'd need to reverify).
    • The necessity of the mentioned elements to always have an accessible name will vary. For instance, ARIA requires a dialog have an accessible name, but then other roles (and thus their HTML elements) like nav, main, banner (header) do not require an accessible name. When there are multiple instances of these elements/roles on a page, the need for providing accessible names can increase. e.g., two search, navigation or complementary landmarks.
    • A section for instance, we would not want to have authors add accessible names to unless they specifically want those sections to be promoted to role=region landmarks. Too many landmarks on a page can dilute their usefulness. Similar for header and footer. Similar issues would arise from auto-naming footer, header, aside.
    • Where automatic naming from the first heading would be helpful, per the issue that @jnurthen provided, imo, would be dialog, search and article. (Note: this is purposefully different from the roles in the linked ARIA PR, as in those cases authors would be specifically defining the roles of the elements, but in HTML the roles of some elements are contingent to their location in the DOM (scoped to body, or main, for instance), and we wouldn't want a bunch of new landmarks popping up in places they shouldn't be. E.g., a header, containing a heading, within a section within an article - we would not want that to become a named role=banner.
    • Another thing to consider, there are other elements in ARIA / HTML which can be named from authors when situations arise where it might be helpful to do so. For instance, <ul> can be given a name. But, we would not necessarily want authors to start adding headings as descendants of lists or their list items.

    FWIW, and this is specifically my own personal opinion, I am very much in favor of HTML adding an alternative mechanism beyond title to name elements which have implicit ARIA roles which allow for naming from authors. I would be very happy to see automatic naming from headings for elements like dialog and article. For other nameable elements, I would tend to lean more towards an explicit association with an element. For instance:

    <!-- the following are not formal attribute name proposals -->
<section namefrom=id> 
  <h# id=id>My heading and name</h#>
  ...
</section>

<!-- or -->
<p  namefor=foo>Groceries</p>
<ul id=foo>...</ul>

    If there is a new element to specifically allow for naming, that would also make sure that elements that don't always need names wouldn't be automatically named from their headings. I just don't have a good idea how that'd help out other HTML elements, per my list example, where the new HTML element wouldn't necessarily make sense as a child of the list. At least, not without updating the content model.

    I know that OpenUI has been kicking around the idea of <tooltip>, so I would want to check in on that more before talking about what to do with descriptions. But at a high level, I'd personally also want a way to associate content (elements) with each other.

    I am very interested in other people's thoughts on this subject.

  4. domenic commented on Nov 10, 2021

    @domenic
    domenic
    on Nov 10, 2021
    MemberAuthor

    @carmacleod had raised an issue about this last year (specifically for landmarks).

    Oh no, I'm so sorry I forgot about that issue; how embarrassing! That issue has a lot of good solutions brainstorming... um... let me close this one and we can move the discussion back over there, although I appreciate the time you gave to help answer my questions and I'll try to use that momentum in that thread.

  5. domenic
    closed this as completedon Nov 10, 2021

  6. aardrian commented on Nov 10, 2021

    @aardrian
    aardrian
    on Nov 10, 2021

    I think @domenic's and @scottaohara's discussion is a good primer set of questions / challenges and should be copied over to the old issue now that this has just been closed.

  7. patrickhlauke commented on Nov 10, 2021

    @patrickhlauke
    patrickhlauke
    on Nov 10, 2021
    Member

    coming in late, but just on this point

    It only accepts strings, not HTML. This means it loses important capabilities like supscripts/superscripts, ruby, language and directionality markup, etc. /cc @whatwg/i18n who have brought up this sort of thing a good deal in the past.

    I'd note that, unless I'm missing something, that is mostly irrelevant because assistive tech will announce even actual rich HTML referenced via aria-labelledby as an uninterrupted/unstructured text stream (without mentioning any further underlying roles etc of the content being referred to)

  8. scottaohara commented on Nov 10, 2021

    @scottaohara
    scottaohara
    on Nov 10, 2021
    Contributor

    yes, true. i was reading that part more as a short coming of title itself being completely unable to allow for structured content. Whatever the new mechanism would still have a flattened string for the accName / description - but if as an actual HTML element, it would at least be available in the DOM for parsing itself.

    something to think about / a potentially greater issue than just creating a way for HTML to name / describe elements that doesn't rely on ARIA (or title).

  9. tabatkins commented on Nov 11, 2021

    @tabatkins
    tabatkins
    on Nov 11, 2021
    Contributor

    I'd note that, unless I'm missing something, that is mostly irrelevant because assistive tech will announce even actual rich HTML referenced via aria-labelledby as an uninterrupted/unstructured text stream (without mentioning any further underlying roles etc of the content being referred to)

    Given that they read normal rich text appropriately, I'd prefer to treat that as just a (significant!) failing of the current assistive tech, rather than something we assume as standard design. It's, uh, extremely bad.

  10. patrickhlauke commented on Nov 11, 2021

    @patrickhlauke
    patrickhlauke
    on Nov 11, 2021
    Member

    sure. but also consider - taking the aria-labelledby example - that at that point, the user's reading cursor/focus is in one spot, and the AT is reading out content from another place. if it were to start announcing things in very complex ways, that sort of content is usually what an AT user would want to read/consume in a more interactive way (advancing line by line, maybe spell things out character by character, jump between headings, list items, etc). that's obviously not possible while the cursor/focus is in a completely different spot (which is why it's generally bad to pass along references to lengthy/structured content this way, since it's invariably vomited out as one big uninterrupted linear text dump.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    a11y-trackerGroup bringing to attention of a11y, or tracked by the a11y Group but not needing response.accessibilityAffects accessibility

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions