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.

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

Consider prohibiting author naming certain roles #833

Open
joanmarie opened this issue Oct 26, 2018 · 11 comments

Comments

Projects
None yet
7 participants
@joanmarie
Copy link
Contributor

commented Oct 26, 2018

At the present time, 5.2.7.4 Roles Supporting Name from Author says:

All roles support name from author with two exceptions. The roles that do not support name from author are presentation and none.

Prior to role parity, that might have been fine. But as we work on the "generic" (real name to be confirmed) role and similar roles, I question whether or not we want the author to be able to name everything (e.g. what about paragraph?).

Related: I personally don't think a div or span element which lacks an ARIA role should be able to be given a name via aria-label or aria-labelledby. But I'm pretty sure the language of the AccName spec and the HTML-AAM permit doing so. (To what avail, who knows? Screen readers might not see fit to present -- or even check for -- a name on a div or span. And if they do, I am not aware of any guidance regarding the expected presentation.)

@jnurthen

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

(comments welcome - this is only my personal opinion - no group consensus is implied)

Taking the current ARIA Roles I would propose we prohibit names on the following

  • blockquote
  • caption
  • listitem
  • paragraph
  • presentation (already prohibited)
  • none (already prohibited)

Potentially add the following after resolving other issues

  • definition (filed issue #836 ) - potentially move to prohibited list based on outcome
@carmacleod

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2018

Agree with most, but not sure about listitem? For example, a list containing icon font characters might use aria-label (or labelledby) to give a pronounceable name to each listitem?
Of course, the author could just add a span with role "img" as a child of the listitem and put aria-label on the span, so if we prohibit names on listitems, we need an example to show how to do this.

<li>
 <span role="img" class="unpronounceable-symbol" aria-label="The Artist Formerly Known as Prince">
 </span>
</li>
@carmacleod

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2018

Is name currently prohibited on presentation/none?

The Presentational Roles Conflict Resolution section says (twice!):

Host languages elements, having implicit presentational roles for which no roles, may be applied, MUST never be exposed to in the accessibility tree. With this exception, user agents MUST always expose global WAI-ARIA states and properties to accessibility APIs. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics.

and again:

User agents MUST always expose global WAI-ARIA states and properties to accessibility APIs, even if an element has an explicit or inherited role of presentation. In this case, the user agent ignores the presentation role and exposes the element according to its implicit native semantics.

(We should remove one of those paragraphs because it's redundant), however the point is that even if they are prohibited on presentation/none, aria-label, aria-labelledby and aria-describedby, being global WAI-ARIA properties, are supposed to be exposed, which puts them in some kind of grey area (not-allowed-but-used-anyhow).

@jnurthen

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2018

Is name currently prohibited on presentation/none?

I understand I was being a little simplistic with my already prohibited comment for none/presentation. Labelling none/presentation causes ARIA to move into an author error correction case and the element falls back to its native role.

@jnurthen

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2018

Agree with most, but not sure about listitem? For example, a list containing icon font characters might use aria-label (or labelledby) to give a pronounceable name to each listitem?
Of course, the author could just add a span with role "img" as a child of the listitem and put aria-label on the span, so if we prohibit names on listitems, we need an example to show how to do this.

<li>
 <span role="img" class="unpronounceable-symbol" aria-label="The Artist Formerly Known as Prince">
 </span>
</li>

I don't see why this is any different than for paragraph. The main issue which I see people using this to resolve is that there is no way of excluding content from ::before and ::after from the accessible name calculation even if it should be excluded. IMO if we solve this problem then we solve the majority of use cases for adding names to "blocks of text"

@carmacleod

This comment has been minimized.

Copy link
Contributor

commented Nov 7, 2018

Right.

But more to the point of this issue, the section on Global States and Properties says:

Some states and properties are applicable to all host language elements regardless of whether a role is applied.

So maybe the easiest way to spec "prohibiting author naming certain roles" is to remove aria-label, aria-labelledby and aria-describedby from the list of global attributes, and then list them separately on all of the roles that don't prohibit their use?

That would solve the "grey-ness" of authors incorrectly giving a presentation/none a name, because in the same conflict resolution section for presentation, it is also stated (twice! :) that:

However, user agents MUST ignore any non-global, role-specific WAI-ARIA states and properties, unless it is on an inherited presentational role where an explicit role is applied.

So anything like: <ul role="presentation" aria-label="My List"> would be both prohibited and ignored, which would be more consistent/predictable (i.e. not grey).

@carmacleod

This comment has been minimized.

Copy link
Contributor

commented Dec 2, 2018

Regarding aria-describedby specifically, can anyone think of legitimate use cases for having aria-describedby on a plain (without a role) div or span? Perhaps to add a tooltip? Or an error or warning message?

@jcsteh

This comment has been minimized.

Copy link

commented Dec 13, 2018

Generally, I think author naming of text containers is potentially problematic. Whether it should be prevented altogether is tricky, though.

Two edge cases come to mind.

First, take a message in some messaging app:

<div role="listitem" aria-labelledby="author message">
  <span id="author">Jamie</span>
  <span id="message">Some message <a href="#">with a link</a></span>
  <button>Reply</button>
  <button>Delete</button>
</div>

The app might provide shortcut keys to focus each message (listitem). Using screen reader as an example, it's nicer for users to just hear a short summary in this case, rather than hearing "Reply Delete" appended to the message text (which isn't useful in this context). However, we don't want authors to think this will completely override the content of the listitem; screen reader users still need to be able to access those controls.

Second, take a configuration system where font weight is used to indicate a non-default value:

<div role="table">
  <div role="row">
    <div role="cell">browser.urlbar.autoFill</div>
    <div role="cell"><b>false</b></div>
  </div>
</div>

The author needs some way to indicate to non-visual users that this is a non-default value. The intuitive approach is to use aria-label (ug):

<div role="cell" aria-label="false (user specified)">false</div>

At least with NVDA, this doesn't work as expected; see #756 (comment) to understand why. While cell isn't being considered for label prevention here, this example can be generalised to any text container; cell isn't "special" in this respect. So, if this change were made, the spec itself would prevent this from working as expected.

Personally, I tend to think we need some way of separating the idea of "label" and "content" for text containers. A listitem might have a "label" which is different from its "content" as per the first example above. It doesn't make sense for an author to set a paragraph's "label", but they may want to override its "content" as per the second example above.

@pkra

This comment has been minimized.

Copy link
Member

commented Dec 13, 2018

Personally, I tend to think we need some way of separating the idea of "label" and "content" for text containers. A listitem might have a "label" which is different from its "content" as per the first example above. It doesn't make sense for an author to set a paragraph's "label", but they may want to override its "content" as per the second example above.

+1

More use cases for this can be found in SVG descriptions and equation layout, including the reverse situation where the "label" (in Jamie's sense) might need to be more than the sum of its parts - and even both more and less.

For the OP, text with PUA codepoints comes to mind as something that might need a aria-label but no role; this occurs fairly reliably in scientific content. But I'm guessing the generic role in #699 could be added to such an aria-label.

@aleventhal

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2018

Could we:

  1. In the spec, disallow names on role-less elements, so that tools spit out an error.
    and 2) Provide language in an AAM or somewhere, on what browsers should do in the error case, e.g. treat it like a role of group when there was a name but no role.

@jnurthen jnurthen removed Agenda labels Jan 10, 2019

@jnurthen jnurthen added the F2F label Mar 5, 2019

@mcking65

This comment has been minimized.

Copy link
Contributor

commented Mar 21, 2019

Consider prohibitting naming of insertion and deletion added for issue #526.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.