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

Tablist roles, states, and properties: aria-label guidance seems unnecessary #2319

Open
smhigley opened this issue May 13, 2022 · 7 comments
Labels
editorial Changes to prose that don't alter intended meaning, e.g., phrasing, grammar. May fix inaccuracies. Feedback Issue raised by or for collecting input from people outside APG task force

Comments

@smhigley
Copy link
Contributor

In the tablist's roles, states, and properties list, the third bullet reads as follows:

If the tab list has a visible label, the element with role tablist has aria-labelledby set to a value that refers to the labelling element. Otherwise, the tablist element has a label provided by aria-label.

The sentence after "Otherwise" seems to imply that a tablist must have an accessible name, and should be given one through aria-label if there is no visible name. If the intent is to imply that a name is required, it seems like something worth revisiting since many traditional application tablists do not have names. Especially if there is no visible name, it seems like adding a specific screen-reader-only name should be optional.

I think we should consider removing the "Otherwise..." sentence, or altering it to say "Otherwise, the tablist element may have a label provided by aria-label."

@JAWS-test
Copy link

Yes, especially because tablist does not have an "Accessible Name Required".

@mcking65
Copy link
Contributor

The section titled "Accessible Name Guidance by Role" starts out:

Certain elements always require a name, others may usually or sometimes require a name, and still others should never be named. The table below lists all ARIA roles and provides the following information for each :

Necessity of Naming: Indicates how necessary it is for authors to add a naming attribute or element to supplement or override the content of an element with the specified role. This column may include one of the following values:

  • Required Only If Content Insufficient: An element with this role is named by its descendant content. If aria-label or aria-labelledby is applied, content contained in the element and its descendants is hidden from assistive technology users unless it is also referenced by aria-labelledby . Avoid hiding descendant content except in the rare circumstances where doing so benefits assistive technology users.
  • Required: The ARIA specification requires authors to provide a name; a missing name causes accessibility validators to report an error.
  • Recommended: Providing a name is strongly recommended.
  • Discretionary: Naming is either optional or, in the circumstances described in the guidance column, is discouraged.
  • Do Not Name: Naming is strongly discouraged even if it is technically permitted; often assistive technologies do not render a name even if provided.
  • Prohibited: The ARIA specification does not permit the element to be named; If a name is specified, accessibility validators will report an error.

We developed those 6 levels of guidance because the ARIA specification only has three choices: required, not required, and prohibitted. Not required simply means allowed, and that doesn't really help authors know whether naming is extremely beneficial, potentially beneficial, or potentially problematic. The spec can say what is "supported" or "allowed", but it is not intended to help people understand what to do with the flexibility given to them by the spec.

For tablist, the table includes:

Recommended

  • Helps screen reader users understand the context and purpose of the tablist.
  • Use aria-labelledby if a visible label is present, otherwise use aria-label .
  • See the Carousel Design Pattern and Tabs Design Pattern.

Given this, would you still like to have some adjustment to the wording? We could change it to, "Otherwise, it is recommended that ". If we did that, it would need to be changed in many patterns.

@mcking65 mcking65 added editorial Changes to prose that don't alter intended meaning, e.g., phrasing, grammar. May fix inaccuracies. Feedback Issue raised by or for collecting input from people outside APG task force labels May 16, 2022
@RobGallo
Copy link

I agree with @smhigley . The current text makes it sound like authors must provide either aria-labeledby or aria-label. The text should be change to indicate that if a visible label exists, authors must provide a label. Otherwise, a label is not required.

@mcking65
Copy link
Contributor

@RobGallo wrote:

I agree with @smhigley . The current text makes it sound like authors must provide either aria-labeledby or aria-label. The text should be change to indicate that if a visible label exists, authors must provide a label. Otherwise, a label is not required.

Are you requesting that the naming guidance be changed from recommended to something else?

@smhigley, are you requesting the task force not recommend naming tablists?

@RobGallo, as I mentioned above, the APG naming guidance does not include an option for "not required". The options we have are:

  • Recommended: Providing a name is strongly recommended.
  • Discretionary: Naming is either optional or, in the circumstances described in the guidance column, is discouraged.
  • Do Not Name: Naming is strongly discouraged even if it is technically permitted; often assistive technologies do not render a name even if provided.

The current guidance for tablist is "recommended". Please see the naming table for details.

@RobGallo
Copy link

@mcking65
Based on the options you've given, I suppose the only choice is discretionary. However, that isn't really good guidance. The best guidance is that if the author thinks that anyone needs the tablist to have a (visible) name, everyone should have access to the name (aria-labeledby).

As you know, tablists almost never have names, and there is no negative accessibility impact to that. The only time a tablist should have an accessible name is when the page author has given the tablist a visible label. The reason being parity.

@craigkovatch
Copy link

craigkovatch commented Jul 9, 2024

Bumping this as it seems like a straightforward change with unanimous consensus, anything blocking it as a revision?

  • Use aria-labelledby if a visible label is present,otherwise use aria-label.

@css-meeting-bot
Copy link
Member

The ARIA Authoring Practices (APG) Task Force just discussed Tablist naming guidance.

The full IRC log of that discussion <jugglinmike> Topic: Tablist naming guidance
<jugglinmike> github: https://github.com//issues/2319#issuecomment-2216737574
<jugglinmike> Matt_King: the "tabs" pattern suggests that a tab list should have an accessible name
<jugglinmike> Matt_King: Name is not required for tab list by the ARIA specification
<jugglinmike> Matt_King: ...so the current language is probably not appropriate because it sort of implies that a name is required
<jugglinmike> Matt_King: We say that the name is recommended for tab list. I actually think that's a good idea
<jugglinmike> Matt_King: We express the importance of naming with four different levels: required, recommended, discretionary, and "do not name"
<jugglinmike> Matt_King: This one, for tab list, we currently have as "recommended"
<jugglinmike> Matt_King: There's some argument here that it should instead be "discretionary" and "do not name"
<jugglinmike> Matt_King: But if we look at the use-cases we have in the APG, there is no visible name and a accessible name provides clear benefit
<jugglinmike> Matt_King: So, in my mind, that justifies either "recommended" or "discretionary"
<jugglinmike> jongund: Do screen readers consider a grouping label, like if you go into a tab list, does it read the name?
<jugglinmike> Matt_King: Well, they should, and it's something we can test in ARIA-AT
<jugglinmike> Matt_King: in the carousel JAWS doesn't say "tab list" which isn't great (although it does tell you when you're on a tab)
<jugglinmike> jongund: I think that's an even stronger reason to recommend it--there's a known user benefit
<jugglinmike> Matt_King: If there *is* a visual label, then there should be a screen reader label. If there's *not* a visual label, then at least one person in this issue was saying that there shouldn't be a screen reader label
<jugglinmike> Matt_King: ...though I still think there's benefit to a screen reader label in cases like the carousel
<jugglinmike> Matt_King: But this shouldn't be about my opinions. Do you use this pattern much in your products, CurtBellew?
<jugglinmike> CurtBellew: I advise a name
<jugglinmike> jongund: I think one thing we may want to consider is whether there is a visible label for the tab list. That seems to be a stronger argument
<jugglinmike> jongund: If there is a visible label, that's an indication that it should be used in this particular case
<jugglinmike> CurtBellew: As in referencing it via "labeledby"?
<jugglinmike> jongund: yeah, that would be the preferred way
<jugglinmike> Matt_King: So if there is no visual label, should it still be recommended to provide an accessible name to the tab list?
<jugglinmike> jongund: If there are multiple tab lists on the page, then you might not recognize that you've moved between the two unless a name is used
<jugglinmike> Matt_King: I have a difficult time thinking about a scenario where there's no benefit at all
<jugglinmike> jongund: I think it would be useful to point out that it's especially useful when there's no visual labels or when there's multiple tab lists on the page
<jugglinmike> Matt_King: We could add a phrase like, "especially when multiple tab lists are present"; but I think it's always helpful
<jugglinmike> Matt_King: Maybe we can write a pull request that makes it more clearly "recommended" rather than vaguely suggesting that it's required
<jugglinmike> Matt_King: I think it appears in multiple places, so we'll have to take care to search the APG for where it needs to be changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial Changes to prose that don't alter intended meaning, e.g., phrasing, grammar. May fix inaccuracies. Feedback Issue raised by or for collecting input from people outside APG task force
Projects
None yet
Development

No branches or pull requests

6 participants