Meeting minutes
<ray-schwartz> +present
new issue triage https://bit.ly/3zewjpf
spectranaut_: scott is not on the call
is there reason for author to maintain both valuenow and valuetext?
jamesn: does it do anything? is it useful?
spectranaut_: need more discussion?
scott: no more to say atm
New PR Triage
scott: add a note to explain non-normative change...
spectranaut_: marked as editorial
keith: I will review
spectranaut_: editorial on defining "host language attr"
ray-schwartz: used language already in the spec... mentions of "host language" in other files. could write a more full definition if we should.
should define "host language" in addition to "host language attribute"
jamesn: add me as a reviewer... i will help ray with the respec addition of a definition
spectranaut_: no need to discuss
WPT Open PRs
<spectranaut_> web-platform-tests/
<jamesn> +1 to that
discussion continued with scribe...
aaron mentioned agreeing with the idea to roll the orphaned tests back
deep dive scheduled july 11th
scott mentioned james's teh's comment. don't roll back the html defaults that were already working... mastadon issue from jcsteh comment on list items
Deep Dive planning
spectranaut_: dive this morning on "undefined" (IDL, string vs state, etc)
spectranaut_: on july 11th, we have the orphaned roles discussion
spectranaut_: any other proposals?
spectranaut_: possibly aria issue 2241? CSS reading-flow proposal
jcraig: I'd like to review it
aaron: also familiar with the feature and it's problem with display:contents... add me to the issue too?
Reminder - no meeting July 4, 2024
spectranaut_: us independence day next week. no meeting
Issue: CSS Highlights Not Clearly Documented in AAM
spectranaut_: aria editors decided that css rules could be added to html-aam
<spectranaut_> jcraig: my only concern about putting css mappings in html aam is that we are less likely to have css editors/feature developers review this document
<spectranaut_> jcraig: they might be more likely to review a spec called "css-aam"
<spectranaut_> jcraig: less weighed down by all the content in html-aam
jcraig: concern with jamming css rules into html-aam... experts from CSSWG less likely to review
jamesn: starting with this. could spilt off later.
jcraig: fair enough
spectranaut_: rahim?
Rahim: will talk with Scott about it.
spectranaut_: digs into css highlight issue
what other issues in aria repo relate to CSS mappings
Rahim: i will create a keyword/tag
jamesn: there were other issue tracked, but no simple way to find them all
<spectranaut_> jcraig: not sure there is a paper trail, look at implementations
spectranaut_: some of the "support" may be determined by reviewing the implementation details
<spectranaut_> jcraig: if it is only just a couple rules, then it doesn't make sense to change the name of the html-aam. if it's more complicated, probably it should be broken off into its own spec
Discussion tracking for ARIA Notification proposal - Scoping / source jamesn]
spectranaut_:
spectranaut_: related to scoping/source.. reads from the issue
notifications can only affect notifications within the same scope... should this be a shared element or something like a shared id string
aaron: element is nice because element already exists… don't need to ask the author for anything
keith: api designed that way now
keithamus: maybe the notification ID in the options bag....? don't think so though
aaron: i will ask Doug to clarify
<spectranaut_> next open question from doug: https://
spectranaut_: asking next aria notify open question
interrupt and flushing... reads from issue linked above
adrian left comment asking for this to be clarified
in the deep dive, doug mentioned odd that higher priority notifications were unable to interrupt lower-priority notifications
jamesn: i agree that's weird
sarah: asked Doug to clarify...
keithamus: my understanding is that the implementation priority is exclusive. higher or lower notifications only affect the same level priority
jcraig: seems like we agree that, as specified, that's not ideal behavior.
sarah: flushing is built into SRs as I understand. is this possible in VO?
<spectranaut_> jcraig: I don't have implementations concerns yet, but it will need to happen. there are enough different ATs that also use speech... we are trying to move anything that makes sense into the engine so it doesn't require duplicated downstream technology. there is some shared AT stuff, but we probably still want to implement as much as possible in webkit
sarah: currently firing aria notify in a particular priority bucket... all interrupt and flushing needs to happen in the Windows SRs... if WebKit did it differently for the sake of downstream ATs on Mac (VO, SC, etc), would that affect the API or implementation?
<spectranaut_> jcraig: part of the problem, is that live regions became more complicated because we relied on screenreaders downstream to handle it. so many implementations outside the webengine... if the scope is web techs, then, as much as possible, it should be defined in the web engine it'sself
sarah: let's discuss more offline