Should :target-current pseudo class also imply aria-current=true on an active scroll marker?

[janewman]

This is being tracked in css-aam in w3c/css-aam#15 and came out of w3c/csswg-drafts#12659

Opening this issue to be able to add to the AriaWG agenda on behalf of @lucasradaelli

[css-meeting-bot]

The ARIA Working Group just discussed Should :target-current pseudo class also imply aria-current=true on an active scroll marker?.

The full IRC log of that discussion

<Zakim> agendum 6 -- -> Should :target-current pseudo class also imply aria-current=true on an active scroll marker? https://github.com//issues/2710 -- taken up [from agendabot]
<spectranaut_> Jacques: I added this for lucas
<sarah> q+
<spectranaut_> dgrogan: this came out of a blog post from sarah....
<jcraig> q+
<spectranaut_> dgrogan: we implemented the suggestion, CSS wanted something firmer from the accessibility group
<spectranaut_> dgrogan: we think it is a good recommendation and it solves a real user problem
<spectranaut_> dgrogan: we'd like to hear agreement or just that no one objects
<jamesn> Ack sara
<jcraig> q+ to agree with using the same platform mapping, but to point out a potential problem with ARIA mapping conflicts re: 'strong native semantics'
<spectranaut_> sarah: I was curious, there was discussion about different implicit roles, there has been talk about scroll markers having different mapped roles both on how they are used, or maybe adding something for authors to change what type of control the scroll marker would be, even those with role none, because aria-current is not valid on every possible role proposed for scroll markers.
<spectranaut_> Daniil: explains....... (scribe missed)
<spectranaut_> sarah: ok this doesn't exactly apply to what I'm talking about (????)
<jamesn> Ack jcraig
<Zakim> jcraig, you wanted to agree with using the same platform mapping, but to point out a potential problem with ARIA mapping conflicts re: 'strong native semantics'
<jcraig> ack me
<spectranaut_> jcraig: so what it currently says, the last paragraph, we should set aria-current=true, setting the dom or content attribute I don't really agree with, that would be a surprised to authors if those attributes change unexpectedly. the native implementation of target current should use the same platform mappings that aria-current uses. don't cross the streams, don't mix and match, aria has this concept called strong native semantics --
<spectranaut_> html wins over ARIA in some cases
<spectranaut_> jcraig: in this particular case, some is coming from pseudo class, dom, etc
<jamesn> q+
<spectranaut_> jcraig: ultimately, there should be a mapping. maybe we will have a scenario where and author mixed the two... we probably want to do what the author wants
<spectranaut_> zakim, close queue
<Zakim> ok, spectranaut_, the speaker queue is closed
<spectranaut_> Daniil: just for styling....
<spectranaut_> jcraig: visiting links are just for styling, but those are communicated to AT
<spectranaut_> jcraig: this should not change the content attributes
<spectranaut_> jamesn: no resolution yet, we need to discuss more next week
<spectranaut_> RRSAgent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/01/22-aria-minutes.html spectranaut_
<jcraig> visiting links are just for styling, but those are communicated to AT/you said this is "just for styling" but many think :visited links are just for styling, but those are communicated to AT; so this can be the same in the native mapping/
<jcraig> s/this should not change the content attributes/this should NOT change any content attributes like aria-current/
<jcraig> s/don't cross the streams,/add an author note to not cross the streams,/
<jcraig> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2026/01/22-aria-minutes.html jcraig
<spectranaut_> zakim, end meeting

[davidsgrogan]

@cookiecrook

jcraig: so what it currently says, the last paragraph, we should set aria-current=true, setting the dom or content attribute I don't really agree with, that would be a surprised to authors if those attributes change unexpectedly.

In case that was targeted at:

In Sara's simple scrollspy demo, if you click on "Section Three" in the nav list, should its Section Three anchor tag get an implicit aria-current=true?

Yes, of course. Explicitly changing the source document would be bad. Apologies for the imprecise terminology. Attempt 2:

In that example, should the Section Three anchor tag be exposed to Assistive Technology with an aria-current state of "true", in the same way it would if the attribute were explicitly present?

[danielsakhapov]

Here is a more formal description of the issue and the proposal to mitigate any misunderstandings:

Problem

When using scroll-target-group: auto on a container, the browser automatically tracks which child <a> link points to the element currently in view. We call this the active scroll marker.

Right now, the browser exposes this state to CSS (via :target-current), but not to Assistive Technology. To make this accessible, authors will be forced to write JavaScript just to toggle aria-current="true".

Proposal

If a link is determined by the browser to be the active scroll marker within a group:

• It should implicitly map to aria-current="true" in the accessibility tree.
• No attribute injection: This doesn't change the DOM; it just updates the platform mapping.
• Author preference: If an author manually sets aria-current, that should still win.

Outcomes

• Parity: If a sighted user sees a "current" highlight (via :target-current), a screen reader user should hear "current."
• Efficiency: The browser already did the math to find the active link for CSS styling. We should just expose that same logic to the A11y tree.
• Cleaner Code: Authors can build accessible carousels and tables of contents with zero JS.

Examples

1. Table of Contents

As the user scrolls to Section 2, the browser identifies that link as the active marker.

<nav style="scroll-target-group: auto;">
  <a href="#sec1">Section 1</a>
  <a href="#sec2">Section 2</a> 
</nav>

AX Tree Result:

• Link "Section 1"
• Link "Section 2" [State: current="true"]

2. Image Carousel (Tab Pattern)

Even if the author uses buttons or different roles, the logic remains consistent.

<div role="tablist" style="scroll-target-group: auto;">
  <button role="tab" href="#img1">Image 1</button>
  <button role="tab" href="#img2">Image 2</button>
</div>

AX Tree Result:

• Tab "Image 1"
• Tab "Image 2" [State: current="true"]

Extra bits considered

If a user scrolls fast, will the Screen Reader keep announcing 'Current, Current, Current' as the active marker shifts?

No. Standard Screen Reader behavior is to announce state changes only when:

• You're looking at an element: If you're focused on the link while it becomes active.
• You asked for it: If it's inside a live-region (which nav links usually aren't).

Is aria-current=true the right value, shouldn't it be aria-current="location" or aria-current="step"?

While aria-current="true" is a safe and valid catch-all, we would like the WG's guidance on the specific token. However, since scroll-target-group is mostly used for pagination (steps) and section navigation (locations), a generic true mapping provides a flexible baseline.

[css-meeting-bot]

The ARIA Working Group just discussed Should :target-current pseudo class also imply aria-current=true on an active scroll marker?, and agreed to the following:

• RESOLVED:

The full IRC log of that discussion

<Zakim> agendum 4 -- -> Should :target-current pseudo class also imply aria-current=true on an active scroll marker? https://github.com//issues/2710 -- taken up [from agendabot]
<jcraig> GtiHub: https://github.com//issues/2710
<jcraig> GitHub: https://github.com//issues/2710
<jcraig> jamesn: discussed last week. no comments added. anyone. want to start the queue?
<sakhapov> sakhapov
<jcraig> sakhapov: :target-current psuedo-class proposal related to links within a group, and it's relation to aria-current="true"
<jamesn> q+
<jcraig> s/links/clickables/
<jcraig> jamesn: if we are setting :target-current, and exposing it to assistive tech, we want to right a11y tests
<jamesn> Ack me
<jcraig> wondering if we would be able to get that within testing tools
<dgrogan> q+
<jarhar> q+
<jcraig> sakhapov: i have a limited knowledge of that per browser, but I think you can query dev tools
<jcraig> jcraig: asking whether within a testing tool, we can determine whether aria-current has been set
<jcraig> jamesn: asking as a testing tools manufacturer
<jamesn> Ack dgrogan
<jcraig> sakhapov: if the browser maps it, you should be able to query it
<jcraig> dgrogan: you asked if in certain patterns, could you give an example?
<jcraig> jamesn: breadcrumb pattern... TOC, etc
<jcraig> if we're using this new pseudo class, how can the testing tool validate the author's usage of this pattern
<jcraig> q+
<jcraig> dgrogan: browser can definitely test this.
<jamesn> Ack jarhar
<jcraig> not sure about addtional testing tools
<jcraig> jarhar: internal browser tests verify this for the web engines
<jcraig> but I don't think this is readily available via DOM tests, but probably through WebDriver
<jcraig> jarhar: also can't test aria-posinet or similar ARIA attrs
<jcraig> q+
<jamesn> Ack jc
<Daniel> scribe+
<Daniel> jcraig: We're not going to be changing the aria-current property based on that.
<Daniel> ... We are talking about mapping a representation of the current element within the browsers internal accessibility
<Daniel> ... aria-current is only one path into this state of currency
<Daniel> ... It can be detected in web development tools. I'd say in the web inspector this is added
<Daniel> ... I don't believe that this is easily detectable by third-party test tools
<Daniel> ... But it can be testable through wpt, where we are trying to map accessibility properties as a static copy
<Daniel> ... target current pseudoclass etc would be mapped and would be able to be querried
<Daniel> scribe-
<jamesn> Q?
<Daniel> s/querried/queried/
<jcraig> jamesn: left the discussion last week with a request for resolution to take forward to CSS WG
<jcraig> what would you like the resolution to say
<jcraig> dgrogan: req jcraig draft the resolution
<jarhar> proposed resolution: elements which match :target-current should also have the equivalent a11y mapping of the aria-current=true attribute
<jcraig> if the browser blesses an element with the :target-current psuedo classs, should it get the same mapping as aria-current
<jcraig> jcraig: i think the answer is yes
<jamesn> q+
<jcraig> mattking: if the author declares the aria-current content attr on another element, and the browser's :target-current status conflicts, what should teh conflict resolution be? or should both be exposed as current?
<jcraig> concerns re: verbosity or confusion
<jcraig> jamesn: it's already possible to have multiple levels of "current-ness" on a page... then we get into the situation where there is a "current" conflict within a single group.
<jcraig> can it already happen with aria-current today? yes, it's an author bug
<jamesn> Ack me
<jcraig> might authors be confused if the browser auto applied the current state unexpectedly
<jcraig> q+ bryan
<jcraig> mattking: some places where browser may not auto-apply this... for example, if the browser sees any non-true/false value applied by an author, it should not auto-apply the true value
<jcraig> for example, aria-current="page" on the element or parent element?
<jamesn> Ack bry
<jcraig> bryan: in case of conflict, aria-current can be toggled between diff values
<jamesn> From the proposal “Author preference: If an author manually sets aria-current, that should still win."
<jcraig> if author explicitly applies aria-current="false" on element, will it unapply the psuedo
<jcraig> jamesn: proposal says aria-current content attr or reflected ariaCurrent DOM prop always wins over the pseudo
<jcraig> sakhapov: when you use the psuedo, you set a contract with browsers, so author should one or the other but not both...
<jcraig> jamesn: I think the answer is that both with be exposed to AT if both applied
<jcraig> jcraig: but that would be an author error
<jcraig> mattking: if author specified aria-current=page on the parent, that's the only thing the AT should see.
<jcraig> q+
<jcraig> i've seen examples where AT is cascading "current" to descendants of the current ancestor container
<jcraig> mattking: perhaps should explore specific authoring scenarios
<jcraig> mattking: pseudo should never override the aria content attr
<jcraig> sakhapov: confirmed, that should never happen
<jcraig> q?
<Jacques> q+
<jamesn> Ack jc
<Daniel> scribe+
<Daniel> jcraig: Matt, the scenario that you call out where AT announces current on descendant nodes I think it's an AT bug
<Daniel> ... We could look if that's also a browser bug
<Daniel> MattKing: If you're using a tree widget and aria-current on the tree item but the pseudoclass is on the link inside the tree item, what would happen?
<Daniel> jcraig: I think that we would consider that an authoring error, because they're applying them to different nodes. Best thing for browsers would be to still expose this as authors are supposed to know better
<Daniel> MattKing: Not sure that should be an author mistake
<Daniel> ... I'd rather put everything on the treeitem which is the one that should be focusable
<Daniel> jcraig: In any case authors should not be used both PIs at once according to the current proposal
<jamesn> Q?
<Daniel> ... Or at least that's what the proposal should suggest IMO
<Daniel> Danniel: Not really
<Daniel> scribe-
<jcraig> sakhapov: api is scroll-target-group.
<jamesn> Q?
<jamesn> Ack Jacques
<jcraig> users may not see the styling, so the :target-current psedo can be styled
<jcraig> Jacques: if author applied current to [example], would it no longer apply the pseudo?
<jcraig> q+
<jcraig> dgrogan: from propsal "Author preference: If an author manually sets aria-current, that should still win."
<jamesn> Ack jc
<Daniel> scribe+
<Daniel> jcraig: If an author uses both scroll-target-group and aria-current in the same context and there's a conflict, that'd be an author error
<Daniel> ... if there's direct application of aria-current, then aria-current as specified by the author should win
<Daniel> jcraig: If there's an indirect conflict both of them should be exposed and it should be flagged as an authoring error
<Daniel> Mattking: That should be a browser requirement, third-party tools cannot currently check that
<Daniel> jcraig: True that browsers could know this and log it via console.warning or console.error
<Daniel> ... There should be a way in wpt to validate that but I don't know if there's anything browsers would do differently in that scenario
<Daniel> ... It may be possible for third-party tool vendors via the DOM, or some public API via CSS to check which API is applied
<Daniel> David: computed style on JAvaScript
<Daniel> s/JAva/Java/
<jamesn> Q?
<Daniel> jcraig: In that case we could dtect that is an error because the computed style would detect the presence of both
<jamesn> q+
<Daniel> David: And you also could query for a different style
<dgrogan> s/David/sakhapov
<Daniel> jcraig: I don't think these testing tools can do that
<Daniel> scribe-
<jamesn> resolution
<jcraig> https://www.irccloud.com/pastebin/bo8ZMy6q/
<jcraig> https://www.irccloud.com/pastebin/AhaC4v8W/
<jcraig> proposed resolution:
<jcraig>
<jcraig> If an element is determined by the browser to be the active scroll marker within a group:
<jcraig>
<jcraig> - It should implicitly map to the same platform and internal engine mappings as aria-current="true" in the accessibility tree.
<jcraig> - No attribute injection: This doesn't change the DOM; it just updates the platform mapping.
<jcraig> - Author preference: If an author manually sets aria-current, that should still win.
<jcraig> - if an author uses both scroll-target-group, and aria-current, that is a author error
<jcraig> s/a author error/an author error/
<jcraig> [further discussion of proposal]
<jcraig> jamesn: objections?
<sakhapov> - Author preference: If an author manually sets aria-current on the active scroll marker, that should still win.
<jcraig> RESOLVED:
<jcraig> If an element is determined by the browser to be the active scroll marker within a group:
<jcraig> - It should implicitly map to the same platform and internal engine mappings as aria-current="true" in the accessibility tree.
<jcraig> - No attribute injection: This doesn't change the DOM; it just updates the platform mapping.
<jcraig> - Author preference: If an author manually sets aria-current on the active scroll marker, that should still win.
<jcraig> - if an author uses both scroll-target-group, and aria-current, that is an author error
<jcraig> rrsagent, draft minutes
<jcraig> zakim, end meeting

[cookiecrook]

ARIA WG Jan 29, 2026
RESOLVED:

If an element is determined by the browser to be the active scroll marker within a group:

• It should implicitly map to the same platform and internal engine mappings as aria-current="true" in the accessibility tree.
• No attribute injection: This doesn't change the DOM; it just updates the platform mapping.
• Author preference: If an author manually sets aria-current on the active scroll marker, that should still win.
• if an author uses both scroll-target-group, and aria-current, that is an author error

[cookiecrook]

Scribe Note: I think it was clear the context was:

• If an author uses both scroll-target-group and aria-current [and that results in a value conflict], that is an author error...
  • [In other words, there may still be a case where an author wishes to use both for backwards compatibility until all major browsers support the new API so non-conflicting usage of both APIs should not be treated as an error except in cases of value conflict.]

However the meeting ended before I spotted this distinction, so the bracketed portions are not part of the official resolution.

[davidsgrogan]

Follow-up: we derived a solid resolution... but what spec should that live in? css-overflow-5 where :target-current is defined? Or a hypothetical css-aam as discussed in #2496?

[pkra]

Follow-up: we derived a solid resolution... but what spec should that live in? css-overflow-5 where :target-current is defined? Or a hypothetical css-aam as discussed in #2496?

CSS-AAM is not quite so hypothetical anymore: #2673

[davidsgrogan]

@pkra, Great to see there is progress on putting up a CSS-AAM spec. Are you saying that once CSS-AAM is live, that's where this resolution should be specified?

[ZoeBijl]

@davidsgrogan that’s correct! @jcsteh and I are in the process of getting the band back together as it were. CSS-AAM would be the right place for this resolution. I’m happy to discuss this further with Jamie, any suggested spec prose would be appreciated though!

[davidsgrogan]

Great. @danielsakhapov can help with translating the above resolution to spec text but possibly not until a spec exists so he can see what's already been defined.