Must focusable elements have a role?

[jamesjacobs]

Would appreciate peoples thoughts / guidance on this one.

Say I have a datatable with many columns. The table only contains textual data - nothing focusable. The table is wrapped by a <div> which has a fixed width and scrolls horizontally to reveal columns hidden by overflow. To ensure keyboard access, the wrapping <div> has tabindex="0" to allow the ability to scroll the table contents horizontally by arrow keys on focus.

Super basic code example:

<div style="width: 500px; overflow-x: auto" tabindex="0">
  <table>
  ...
</div>

My question is, should the wrapping div that can gain keyboard focus have a role (either implicit or explicit)? I was under the impression it didn't need one, but I'm seeing IBM Equal Access checker flag it as a failure under 4.1.2 - stating that tabbable elements should not have the role of "none".

I appreciate that tools can get things wrong or just flag things to manually verify but I've been unable to find anything concrete as to if focusable elements, such as this one, must have an appropriate role - as focusable elements typically have a role by default (or should do).

TIA

[patrickhlauke]

normative MUST? no. as a best practice, probably, but not really required anywhere. seems IBM Equal Access is overreaching here in failing this under 4.1.2, I'd say.

related (if the PR ever gets merged) https://github.com/w3c/wcag/pull/1643 which clarifies that it's also not a failure (of Focus Order or otherwise) if a static/non-interactive element receives focus (within "reason")

[patrickhlauke]

Closing the loop https://github.com/IBMa/equal-access/issues/1305

[philljenkins]

If the element doesn't have a valid role, then how is the blind screen reader user going to know how to interact with it?
Name and Role are both required. Depending on the type, then value or state is also required. This Name, Role, and Value was the whole foundation of ARIA and how screen readers work.

Can you have a button without a name or label? No. It's either a violation of 1.3.1. or 4.1.2 Can you have a labelled button you can't operate? No, it's a violation of 2.1.1 Can you have a label/name without a role? No. It's either a violation of 1.3.1. or 4.1.2

And I flagged static elements that received keyboard focus all the time as a violation because the blind screen reader user has no idea why the keyboard focus stopped there if it's not operable. And also as bad, the sighted keyboard user has no idea why the keyboard focus stopped on something that isn't operable.

[patrickhlauke]

If the element doesn't have a valid role, then how is the blind screen reader user going to know how to interact with it?

if it's not interactive, then what role should it expose? as we determined in https://github.com/w3c/wcag/pull/1643 there are cases where static elements can and will receive focus ... heck, a simple skip link that then jumps focus explicitly to a container is one of the more basic examples. what role do you suggest should be exposed there?

I disagree with your take on this @philljenkins, sorry.

[philljenkins]

@patrickhlauke a skip link has a role of link! That's how you (and your user agent) know it's a link (HTML anchor) to click and it will take focus to where the link goes.

any more examples?

[patrickhlauke]

@patrickhlauke a skip link has a role of link!

I'm talking about the TARGET of the skip link, if that's been given a tabindex...

[philljenkins]

Ah, I took a look at https://github.com/w3c/wcag/pull/1643 which includes some examples of some static content receiving focus.

• Skip links move focus to the static content, but the link you clicked (sent you there) still has a link role.
• Tab pane: they receive focus and although not directly operable, the user knows to arrow (or tab) to get to the next operable tab to open
• Adding tab stops to static content (in particular, instructions on forms), so not directly operable, but could be if in a scrollable container

So now I think I see your point - does static content that receives focus have to always have a valid operable role? Well, probably not, and that's your point (smile). We will need to review the ARIA spec to make sure that's the case too.

We'll look at softening the rule as well.

[patrickhlauke]

any more examples?

i seem to remember we listed some more cases in https://github.com/w3c/wcag/issues/1572

[patrickhlauke]

thanks @philljenkins ... sorry, had a momentary bit of defensiveness there for a second...

We'll look at softening the rule as well.

perhaps making it a strong warning rather than an outright fail, a la "do a manual check and make sure there's a good reason this thing receives focus. this is often an indication that it's a custom interactive control, and if THAT's the case, it will fail 4.1.2 for missing at least a role" (sorry, crammed lots of nuance in there, but you get my point)

[tombrunet]

As far as https://github.com/IBMa/equal-access/issues/1305, two items:

First, there seems to be a missing distinction here between focusable and tabbable. For the most part, tabbable elements are a subset of focusable elements, but they are not one and the same. See https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation. Any element with tabindex="-1" is focusable, but it is not tabbable.

On that note, this issue and https://github.com/IBMa/equal-access/issues/1305 are completely separate issues. I believe the answer to this issue is No, focusable elements don't need a role. However, I believe the rule regarding tabbable is valid.

WCAG 4.1.2 states:

For all user interface components ... role can be programmatically determined

A tabbable element is a user interface component because it is perceived by a keyboard user as "as a single control for a distinct function" and therefore must have a programmatically determined role.

The idea that tab order is intended for interactive components and not content is evidenced by browsers not making landmark regions and headings as part of the tab order by default.

In terms of examples, consider the skip example. First, native skip links are neither focusable nor tabbable (see https://codesandbox.io/s/link-target-hi3t0o?file=/index.html). Even if you made the jump targets focusable, there's no reason to make them tabbable. What is the thing you've tabbed to? What happens when I interact with it via enter or spacebar. Nothing. Then, what is this thing and why am I tabbing to it?

(edit - forgot to add the second point) As to your request to downgrade our rule to a best practice, if you use the tools with the WCAG guidelines, it will flag as a recommendation. The default is to check using IBM guidelines. This particular rule is fairly new, so we haven't upgraded it to a violation for WCAG. We're also stricter in requiring usage of landmarks (which aren't required by WCAG)

[patrickhlauke]

@philljenkins @tombrunet so you're failing anything that gets focus from tabbing/is in the tab order, but is not interactive, under 4.1.2? again, this seems an overinterpretation to me

if the rest of the WG agree though, this definitely must be clarified/specified in the 4.1.2 understanding document at the very least, and cross-referenced from the understanding change proposed in https://github.com/w3c/wcag/pull/1643

[patrickhlauke]

As to your request to downgrade our rule to a best practice, if you use the tools with the WCAG guidelines, it will flag as a recommendation. The default is to check using IBM guidelines.

Ah, my apologies. As I don't directly use the tool, I took the OP here to mean it was failing it as a straight-up WCAG guidelines violation. perhaps, then, it may be worth noting in the rule that it may be stricter than some more lenient WCAG interpretations?

EDIT: I've now given this a whirl on a little test page, and I can see what you mean - switching to WCAG ruleset specifically shows this as an info/recommendation,

and I see that switching to the IBM ruleset, it's flagged a violation, but includes the following note

Note: IBM considers this a violation of WCAG Success Criteria. Others may use a strict interpretation of the criterion and may only recommend this to be fixed. However, there is broad agreement that putting inoperable elements in the tab order has an accessibility impact on users. 

[tombrunet]

Some other evidence that w3c intends tab to just be interactive items: https://www.w3.org/TR/2015/NOTE-UAAG20-Reference-20151215/#sc_221

The user can move the keyboard focus backwards and forwards through all recognized enabled elements

Intent of Success Criterion 2.2.1: Sequential keyboard navigation is a fundamental, universal method of keyboard access. While it can be slower and require more input than other methods (such as direct, structural, or search-based navigation) it is a simpler mechanism that requires very little cognitive load or memorization, and is consistent across contexts.

Enabled elements:

An element with associated behaviors that can be activated through the user interface or through an API.

In other words, the tab navigation is there to move just between elements that you can interact with. Adding structural navigation and other non-interactive content to the tab order adds cognitive load. Adding non-interactive content to the tab order is a mis-use of the function.

[philljenkins]

Is Understanding 2.4.3 Focus Order also being addressed in #1572 ?

The understanding doc seems to also use the term "focusable components" and navigated sequentially without defining or distinguishing between tabbable and focusable. It should address the sense of static content that can receive focus but without being in the tab order (in the tab index) and navigated sequentially.

A correct reading (not tabbable) sequence of course is still required by Understanging 1.3.2 Meaningful Sequence.

REviewing the examples in https://github.com/w3c/wcag/pull/1643 and cases in https://github.com/w3c/wcag/issues/1572 I don't find any "static content like" examples that should be in the tab order that are not operable, except:

• a scrollable <div> that is made focusable tabbable so keyboard users can tab to it and easily scroll it with arrow keys. Firefox makes <iframe> and scrollable elements focusable by default, while Chrome requires a tabindex or a tabbable element in the container. See ACT rule 0ssw9k Scrollable element is keyboard accessible
• static content focusable, so that the tooltip can be shown on focus

[patrickhlauke]

Is Understanding 2.4.3 Focus Order also being addressed?

https://github.com/w3c/wcag/pull/1643 is about one aspect of 2.4.3. @mbgower did mention the distinction between focusable and tabbable in https://github.com/w3c/wcag/issues/1572#issuecomment-1125320494 there in the context of IBM discussions, but there's not been a proposed tweak/addition/change in this respect to 2.4.3 understanding. suggest somebody file a PR (i'll abstain for a bit, as i've already got a sizeable amount just sitting in purgatory at the moment)

[patrickhlauke]

I don't find any "static content like" examples that should be in the tab order that are not operable

one of the points of #1643 came down, effectively, "how strict are we about things that yes, really shouldn't be tabbable, but don't cause an issue". mainly because i've seen far too many cases where auditors fail even a single pointless, but harmless, static container set to tabindex="0" as a hard 2.4.3 problem, and whether that's too harsh/strict a view (because of the binary pass/fail nature of SCs, where there's really a lack of nuance between "this is unnecessary and silly, stop it" and "this is a major fault that will make your site completely inaccessible")

[patrickhlauke]

@tombrunet

In other words, the tab navigation is there to move just between elements that you can interact with.

Arguably, that "just" isn't in the original text. From, effectively, "users can tab between interactive controls/elements" you can't directly infer "users can only tab between interactive controls/elements"

and even the definition in WCAG for user interface components

a part of the content that is perceived by users as a single control for a distinct function

is not necessarily unambiguous, as a user may not perceive something as a functional control despite it receiving focus (unless it becomes a circular "by virtue of it receiving focus, the user will perceive this as a functional control" reference)

to be clear, i do understand the reasoning here [edited for clarity]:

• something is in the tab order
• by virtue of it being in the tab order, we say it's a "user interface component* (even though users may or may not "perceive it as being a functional control")
• therefore, we apply 4.1.2 to it, and fail it for not having a widget role (even though it's not an interactive widget)

wondering though if this is a far too strict/mechanistic interpretation. however, if the WG agrees with this, then it needs to be clearly signposted/mentioned in the understandings for both 2.4.3 and 4.1.2

[philljenkins]

I wouldn't say it exactly that way, I would be explicit and replace "something receives focus" with "something in the tab order"

to be clear, i do understand the reasoning here:

something receives focus in the tab order by virtue of it receiving focus being in the tab order, we say it's a "user interface component* (even though users may or may not "perceive it as being a functional control") therefore, we apply 4.1.2 to it, and fail it for not having a widget role (even though it's not an interactive widget)

[patrickhlauke]

I would be explicit

sorry, old habits die hard, but noting that WCAG even in its normative text (for 2.4.3) uses "focusable" to mean tabbable. amended my original comment for clarity. but my point there for discussion remains: is it too harsh an interpretation? and i'm still not 100% convinced about "by virtue of it being in the tab order, we say it's a "user interface component* (even though users may or may not "perceive it as being a functional control")". and whether to fail under 4.1.2 hinges on how somebody would interpret this, i.e. does "tabbable = user interface component" with no further nuance.

this seems in essence one of those "cascades of failure". the actual problem is that an author has made something tabbable that serves no interactive purpose. but we fail it under 4.1.2 for not having an interactive role (when really we'd want to fail it for being unnecessarily focusable, but can't because 2.4.3 is only concerned with the order in which things receive focus, not whether they should or shouldn't?)

[JAWS-test]

@patrickhlauke

as a best practice, probably

What role should a scrollable container have? I don't think anyone has answered this question yet. I don't know of a proper role.

The ACT rule uses the HTML element sections without a label which maps to generic = the same as a div element. Maybe that's enough because generic is a role? But one that is usually not output by the screen reader, even if it is not identical to role=none.

Instead of a role, I think a label (e.g. per aria-label="scrollable area") or aria-roledescription would be better for a scrollable container (like the HTML element section).

[patrickhlauke]

What role should a scrollable container have? I don't think anyone has answered this question yet. I don't know of a proper role.

indeed, there's not a perfectly good widget role that maps directly to "this container has been made focusable so that it can be scrolled". i've seen people initially suggest role="scrollbar", but that's not really a correct fit, as that role is meant for the actual scroller control itself and requires an aria-controls and aria-valuenow.

some folks (like in this short note on scrollable regions) suggest a document structure role like role="region", but then that doesn't quite gel with what @philljenkins was suggesting (that it must be a widget role)

[tombrunet]

The scrollable container is a good exception. We do make an allowance in our rule to allow tabs on scrollable containers since they are interactive components despite not having an ARIA role. In fact, there's a proposed ACT rule that requires the scrollable container or some descendant of that container to be tabbable (https://wai-wcag-act-rules.netlify.app/standards-guidelines/act/rules/0ssw9k/proposed/). Our rule message doesn't highlight that exception since the development mistake on a tab stop with no role is almost certainly that they forgot to give the widget a role rather than they forgot to make a container scrollable.

[patrickhlauke]

@tombrunet just to check...is there a current ACT rule that enshrines the "if it's tabbable, it must have a role value that's not presentation or none"? just asking because, as seen here and in https://github.com/w3c/wcag/issues/1572#issuecomment-1434061864 there's probably not consensus on that aspect, so just want to make sure things aren't getting codified over in ACT or that this somehow slipped through

[tombrunet]

@patrickhlauke I have not seen such an ACT rule yet.

[tombrunet]

BTW, keep in mind that when 4.1.2 was introduced into WCAG, HTML 4 was the latest spec. HTML 4's definition for tabindex was: https://www.w3.org/TR/html4/interact/forms.html#adef-tabindex

The following elements support the tabindex attribute: A, AREA, BUTTON, INPUT, OBJECT, SELECT, and TEXTAREA.

Specificity regarding tabindex use on random content wasn't included because tabindex wasn't allowed on random content. Usage as a global attribute wasn't introduced until HTML5.

[philljenkins]

(unless it becomes a circular "by virtue of it receiving focus, the user will perceive this as a functional control" reference)

"by virtue of it receiving focus" is or should not be the test, it has to do with "how and why" the reading and tabbing focus was moved:

• pressing the tab key: Did the user press a tab key and then landed on some non-interactive static content? The users I've witnessed (sighted keyboard-only users, blind screen reader users, voice users, cognitively impaired users, etc.) including myself will ask why the tab key is stopping there. When there isn't an answer, then it is an accessibility issue, same as focus order, same as no alt (even though the file name may give a clue), etc. My criteria to determine if its an accessibility issue is if it affects more than one set of users, and if it is more adversely affects some set of users, then it's an accessibility barrier that needs a requirement (SC) to remove and a checking rule to flag. The argument that it's not a big deal some of the time or to some users is not the test to use to determine if it is an accessibility requirement. I believe there is broad consensus that it does affect _many users, and affects some_ of them all of the time.
• pressing a link or button: take the reading focus (not tab order) to the static content that insures/preserves the correct sequence (reading order). Examples include moving the reading focus to error messages, or other static content via local anchors is not just correct, but often required, and always is a result of some user action (i.e. pressing a link, checking a form).
• scrollable divs and iframes: these do require the ability for the keyboard users to be able to navigate to them to scroll them with arrow keys. The ACT rule is primarily there because the Chrome browser does not do this correctly or automatically, meaning that in Firefox the scrollable divs and iframes are naturally put in the tab order automatically. The ACT rule is to insure that this navigation and operation can happen correctly in Chrome (and others?). The Equal Access Checker will also flag a scrollable div or iframe that is incorrectly taken out of the tab order by an incorrect tab index whether in Firefox or Chrome. This rule is a slight exception to the role "must be a widget role" (I prefer to describe it as an extension), because it is still programattticaly detectable via the scroll and overflow attributes. It has an "implied" widget role (to the defined list in the ARIA 1.2 spec) that must be keyboard navigable. So the criteria are that the element must have a widget role or needs to be reachable via the tab navigation (e.g. scrollable elements) so it can be operated (scrolled). See ACT rule 0ssw9k Scrollable element is keyboard accessible.

... suggest a document structure role like role="region", but then that doesn't quite gel with what @philljenkins was suggesting (that it must be a widget role)

I believe that it does gel because I'm not conflating tabbable with focusable, who has the responsibility (browser/UAs), and when the user has the choice. Browsers and ATs can (and should) add mechanisms to navigate to regions via the keyboard, but there should be no requirement to make "all" regions be added "always" to the tab order with no user choice. The requirement is about enabling the accessible UX, not creating an inaccessible side effect for other users.

[patrickhlauke]

"by virtue of it receiving focus" is or should not be the test

yes, we established that we want to make the distinction, so treat what i original wrote there as "by virtue of it being tabbable". still a slightly circular logic "people will perceive it as a control for functionality, because they were able to tab to it"

[mbgower]

Another example of a tabstop on non-operable content can be on a tab panel in a tab. The need is similar to that for a scrollable area -- in fact one of the benefits can be that the tabpanel becomes scrollable (where it lacks any item that takes focus, yet has content that exceeds its displayable dimensions).

A further example is on a 'return to top' mechanism. It's possible to reposition the viewport to the top without putting the keyboard focus there, in which case, a keyboard user's point of interaction can remain much further down the page (hence they press 'tab' to precede to the next link they see in the second paragraph, and the page's focus shifts somewhere completely different). A possible solution is to put a -1 tabindex on the top heading.