Skip to content

fix(scrollable-region-focusable): clarify the issue is in safari#4995

Merged
WilcoFiers merged 1 commit intodevelopfrom
scrollable-region-safari
Jan 29, 2026
Merged

fix(scrollable-region-focusable): clarify the issue is in safari#4995
WilcoFiers merged 1 commit intodevelopfrom
scrollable-region-safari

Conversation

@WilcoFiers
Copy link
Copy Markdown
Contributor

@WilcoFiers WilcoFiers commented Jan 26, 2026

Part of #4830

Doesn't close the issue, but people keep reporting this as a false positive because we don't make it clear this is a Safari-only issue. Axe-core explicitly calling out a browser or screen reader is unusual, but I think the problem not doing this creates here is bigger than the overhead it would be for us to keep an eye on this and pull this out. If Safari ever addresses this the rule can be deprecated completely.

See related Webkit bugs:

@WilcoFiers WilcoFiers requested a review from a team as a code owner January 26, 2026 14:28
Copilot AI review requested due to automatic review settings January 26, 2026 14:28
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request clarifies that the scrollable-region-focusable rule is specifically a Safari browser issue by updating the rule's description metadata. This addresses confusion from users reporting false positives, as they were not aware this accessibility issue is Safari-specific. The PR description notes this is unusual for axe-core to call out a specific browser, but the overhead of maintaining this specificity is justified given the user confusion it resolves.

Changes:

  • Updated the description field in the rule's JSON metadata to explicitly mention Safari

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

"metadata": {
"description": "Ensure elements that have scrollable content are accessible by keyboard",
"description": "Ensure elements that have scrollable content are accessible by keyboard in Safari",
"help": "Scrollable region must have keyboard access"
Copy link

Copilot AI Jan 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "help" text should also mention Safari for consistency with the updated "description" field. Users typically see the help text in accessibility testing tools, so it's important to clarify there as well that this is a Safari-specific issue. Consider updating to: "Scrollable region must have keyboard access in Safari"

Suggested change
"help": "Scrollable region must have keyboard access"
"help": "Scrollable region must have keyboard access in Safari"

Copilot uses AI. Check for mistakes.
Copy link
Copy Markdown
Contributor

@straker straker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should make a similar change to the help docs.

@WilcoFiers WilcoFiers merged commit 4ec5211 into develop Jan 29, 2026
30 checks passed
@WilcoFiers WilcoFiers deleted the scrollable-region-safari branch January 29, 2026 16:41
WilcoFiers added a commit that referenced this pull request Mar 30, 2026
Part of #4830

Doesn't close the issue, but people keep reporting this as a false
positive because we don't make it clear this is a Safari-only issue.
Axe-core explicitly calling out a browser or screen reader is unusual,
but I think the problem not doing this creates here is bigger than the
overhead it would be for us to keep an eye on this and pull this out. If
Safari ever addresses this the rule can be deprecated completely.

See related Webkit bugs:

- [WebKit#190870: Make scrollable element
focusable](https://bugs.webkit.org/show_bug.cgi?id=190870)
- [WebKit#277290: AX: Scrolling containers inoperable with
keyboard](https://bugs.webkit.org/show_bug.cgi?id=277290)
straker pushed a commit that referenced this pull request Mar 30, 2026
Part of #4830

Doesn't close the issue, but people keep reporting this as a false
positive because we don't make it clear this is a Safari-only issue.
Axe-core explicitly calling out a browser or screen reader is unusual,
but I think the problem not doing this creates here is bigger than the
overhead it would be for us to keep an eye on this and pull this out. If
Safari ever addresses this the rule can be deprecated completely.

See related Webkit bugs:

- [WebKit#190870: Make scrollable element
focusable](https://bugs.webkit.org/show_bug.cgi?id=190870)
- [WebKit#277290: AX: Scrolling containers inoperable with
keyboard](https://bugs.webkit.org/show_bug.cgi?id=277290)
@straker straker mentioned this pull request Mar 30, 2026
WilcoFiers added a commit that referenced this pull request Mar 31, 2026
### [4.11.2](v4.11.1...v4.11.2)
(2026-03-30)

### Bug Fixes

- **aria-valid-attr-value:** handle multiple aria-errormessage IDs
([#4973](#4973))
([9322148](9322148))
- **aria:** prevent getOwnedVirtual from returning duplicate nodes
([#4987](#4987))
([99d1e77](99d1e77)),
closes [#4840](#4840)
- **DqElement:** avoid calling constructors with cloneNode
([#5013](#5013))
([88bc57f](88bc57f))
- **existing-rule:** aria-busy now shows an error message for a use with
unallowed children
([#5017](#5017))
([dded75a](dded75a))
- **scrollable-region-focusable:** clarify the issue is in safari
([#4995](#4995))
([2567afd](2567afd)),
closes
[WebKit#190870](https://github.com/dequelabs/WebKit/issues/190870)
[WebKit#277290](https://github.com/dequelabs/WebKit/issues/277290)
- **scrollable-region-focusable:** do not fail scroll areas when all
content is visible without scrolling
([#4993](#4993))
([240f8b5](240f8b5))
- **target-size:** determine offset using clientRects if target is
display:inline
([#5012](#5012))
([69d81c1](69d81c1))
- **target-size:** ignore widgets that are inline with other inline
elements ([#5000](#5000))
([cf8a3c0](cf8a3c0))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants