Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
triage w3c/
jamesn: no new PRs
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: no new ones
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: no new suggestions for deep dives
Should :target-current pseudo class also imply aria-current=true on an active scroll marker?
GitHub: w3c/
jamesn: discussed last week. no comments added. anyone. want to start the queue?
<sakhapov> sakhapov
sakhapov: :target-current pseudo-class proposal related to clickables within a group, and it's relation to aria-current="true"
jamesn: if we are setting :target-current, and exposing it to assistive tech, we want to right a11y tests
wondering if we would be able to get that within testing tools
sakhapov: i have a limited knowledge of that per browser, but I think you can query dev tools
jcraig: asking whether within a testing tool, we can determine whether aria-current has been set
jamesn: asking as a testing tools manufacturer
sakhapov: if the browser maps it, you should be able to query it
dgrogan: you asked if in certain patterns, could you give an example?
jamesn: breadcrumb pattern... TOC, etc
if we're using this new pseudo class, how can the testing tool validate the author's usage of this pattern
dgrogan: browser can definitely test this.
not sure about additional testing tools
jarhar: internal browser tests verify this for the web engines
but I don't think this is readily available via DOM tests, but probably through WebDriver
jarhar: also can't test aria-posinset or similar ARIA attrs
jcraig: We're not going to be changing the aria-current property based on that.
… We are talking about mapping a representation of the current element within the browsers internal accessibility
… aria-current is only one path into this state of currency
… It can be detected in web development tools. I'd say in the web inspector this is added
… I don't believe that this is easily detectable by third-party test tools
… But it can be testable through wpt, where we are trying to map accessibility properties as a static copy
… target current pseudo class etc would be mapped and would be able to be queried
jamesn: left the discussion last week with a request for resolution to take forward to CSS WG
what would you like the resolution to say
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
if the browser blesses an element with the :target-current pseudo class, should it get the same mapping as aria-current
jcraig: i think the answer is yes
mattking: if the author declares the aria-current content attr on another element, and the browser's :target-current status conflicts, what should the conflict resolution be? or should both be exposed as current?
concerns re: verbosity or confusion
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.
can it already happen with aria-current today? yes, it's an author bug
might authors be confused if the browser auto applied the current state unexpectedly
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
for example, aria-current="page" on the element or parent element?
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."
if author explicitly applies aria-current="false" on element, will it unapply the pseudo
jamesn: proposal says aria-current content attr or reflected ariaCurrent DOM prop always wins over the pseudo
sakhapov: when you use the pseudo, you set a contract with browsers, so author should one or the other but not both...
jamesn: I think the answer is that both with be exposed to AT if both applied
jcraig: but that would be an author error
mattking: if author specified aria-current=page on the parent, that's the only thing the AT should see.
I've seen examples where AT is cascading "current" to descendants of the current ancestor container
mattking: perhaps should explore specific authoring scenarios
mattking: pseudo should never override the aria content attr
sakhapov: confirmed, that should never happen
jcraig: Matt, the scenario that you call out where AT announces current on descendant nodes I think it's an AT bug
… We could look if that's also a browser bug
MattKing: If you're using a tree widget and aria-current on the tree item but the pseudo class is on the link inside the tree item, what would happen?
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
MattKing: Not sure that should be an author mistake
… I'd rather put everything on the treeitem which is the one that should be focusable
jcraig: In any case authors should not be used both PIs at once according to the current proposal
… Or at least that's what the proposal should suggest IMO
Danniel: Not really
sakhapov: api is scroll-target-group.
users may not see the styling, so the :target-current pseudo can be styled
Jacques: if author applied current to [example], would it no longer apply the pseudo?
dgrogan: from proposal "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 in the same context and there's a conflict, that'd be an author error
… if there's direct application of aria-current, then aria-current as specified by the author should win
jcraig: If there's an indirect conflict both of them should be exposed and it should be flagged as an authoring error
Mattking: That should be a browser requirement, third-party tools cannot currently check that
jcraig: True that browsers could know this and log it via console.warning or console.error
… 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
… It may be possible for third-party tool vendors via the DOM, or some public API via CSS to check which API is applied
David: computed style on JavaScript
jcraig: In that case we could detect that is an error because the computed style would detect the presence of both
sakhapov: And you also could query for a different style
jcraig: I don't think these testing tools can do that
<jamesn> resolution
https://
https://
proposed resolution:
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, that should still win.
- if an author uses both scroll-target-group, and aria-current, that is an author error
[further discussion of proposal]
jamesn: objections?
<sakhapov> - Author preference: If an author manually sets aria-current on the active scroll marker, that should still win.
RESOLUTION:
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
jcraig: 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 conflict]_, that is an author error...
- 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
However the meeting ended before I spotted this distinction, so the bracketed addition is not part of the official resolution.