Meeting minutes
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: Daniel, should we have a convo with them?
Daniel: I was going to reply, what is the real purpose, what is the benefit, in addition to html specifications don't have this list
Daniel: eventually we will probably have to set up a meeting
jamesn: assigning to you
spectranaut_: I asked tyler to do this, you can assign to me
jamesn: Daniel, can we do this?
Daniel: I thought we didn't want to do this, there are old environments that use that aria 1.1 so it's valid for them
jamesn: I'm not convinced the old browser argument works anymore, all browsers auto update now
Daniel: ok, sounds reasonable
jamesn: anyone disagree?
giacomo-petri: I discussed in the WCAG group as well with Kevin, the reason why we are not doing this in WCAG, WCAG has legal requirements. are there legal requirements referencing ARIA 1.1
jamesn: if they are, they should change it
giacomo-petri: ok :)
<aardrian> The legal reason justifies adding the warning, IMO
jamesn: I think personally we might want to add mappings/comment in html-aam to say that this exposes a listbox in this case, so option is a child
jamesn: should we discuss this more?
matt: yeah lets agenda it
editorial
pkra: someone did an AI generated PR that I closed because it showed I underestimate the work
pkra: I saw explict mentions of ARIA 1.2. For example, is deprecated IN aria 1.2, and is should be changed to SINCE aria 1.2, I'll take this one
jamesn: it's f2f candidate, we talk about it then
jamesn: we have discussed this... is this a needs champion?
pkra: maybe a f2f candidate to talk in person about it
matt: we have already had the discussion before
jamesn: seems like no one said in favor of deprecating
Matt_King: we wanted a concrete proposal as a next step, that is why there is an issue
pkra: when we talked about this three years, we talked about not deprecating it until we had a better replacement
jamesn: I'm going to say needs champion
jamesn: someone needs to push forward
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
tyler and jcraig to review
pkra: this is competing to my next PR
pkra: I think either is fine
pkra: I'll assign one of them
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: we can move on from this
TPAC planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: this is a reminder, to add items you want discussed. Val lets find time next week to review these and schedule
jcraig: I'm trying to coordinate WPT meetings as well, so if you have open slots, I need to coordinate meetings with other people
jamesn: can you make a placeholder issue for us?
jcraig: I think we want Browser Testing and Tools cross meeting
jcraig: And then another one just for the ARIA group
Add explicit language and direction metadata to AriaNotificationOptions - quick check on status agendabot]
jamesn: quick check in, clay was assigned to this, daniel do you have updates
Daniel: I think it links to the right PR now, I addressed everyones comments, please approve since my updates.
Daniel: waiting on xfq consent
jamesn: there are a few comments in the PR that haven't been resolved by the look of it
Daniel: I think at this point we should split them, we are all in agreement with the internationalization prose, but the security needs more discussion.
jcraig: yeah can you take out the security thing and make a new PR?
jcraig: if there are commetns we don't want to lose... that might be tricky
jamesn: more are on the internationalization side, so easier to split out security
Editorial: I18n considerations for translatable attributes - reminder to review
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Daniel: ok this is the one I originally thought we were talking about
jamesn: looks like there are comments to be resolved, although I see things have been marked out of date
pkra: it might not be good to make this seem like a reasonable thing to do, it might encourage bad behavior and WCAG violations, it might be more confusing than helpful.
jamesn: can we strengthen this sentence before the example, saying it's likely a WCAG violation to do this
pkra: yeah I tried to add suggestions to make it stronger
pkra: I'm torn because the suggestion is to give examples of how it can go wrong but I can't think of examples of how it can be right.
<jamesn> Strengthen “ It is best practice for authors to ensure that the language and directionality of the value of a translatable attribute matches the language and directionality of its containing element.”
jamesn: "best practice" sounds like it's not a failure, but in fact its almost always a problem, so maybe not the right choice of word
jcraig: I don't have a strong opinion about what the right solution is. screen readers/speech engines are getting better at guessing language changes.. but it's not perfect
pkra: I don't want to take the pressure off us to find a solution for some of these mixed problems
jcraig: I relate to you comment that it feels like the accessibility related specs are challenged on this things which are problems with the main spec, if you want warning language in ARIA, it seems like there should be warning language on the main specs -- HTML etc
<HaTheo> Or a language picker...
sarah: I have the same feelings as Peter, but I can think of an example -- for example a flashcard with aria-label instead of aria-labelleby, or a chat app that is responding about a question about a different language that the UI discussion is happening in
<pkra> such a good point about css content!
sarah: Would it make sense to add CSS content in here as a thing to avoid because it also has all the same language problems and also more problems
<aardrian> +1
Daniel: right so we do need to respond to the ARIA concern, and CSS should be addressed in CSS specs
Daniel: also in terms of the review, addressing the issues with prose is easier than pushing back. This issue is easy to address from editorial perspective, it's just the other fingerprinting issue that would be very complicated to address
jamesn: for those who commented, can you live with whats here? or does it make the spec worse?
jcraig: I think the suggestion to modify the second sentence was a good one
jcraig: this might result in a WCAG practices violation
jcraig: otherwise I think it can stand as is
<aardrian> I'm fine with this language.
<Jacques> lgtm +1
jamesn: I agree, I'm happy with it with that change
pkra: fine with me
Daniel: and not mentioning CSS here
Daniel: I'll update that
Matt_King: quick question about CSS, do you know if AGWG is pointing out that specific failure mode, because it does seem like it's within their purview
aardrian: I thought there was a failure technique
Matt_King: specifically related to the language?
jamesn: not related to the language
Security Horizontal Review - quick check on status
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<sarah> don't see anything in wcag language of parts referencing css directly
Daniel: we need a meeting with Simone
aria-actions: handling focus when actions are synthetically triggered - quick check on status
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
sarah: I need a quick check on something with tyler, jcraig and jacques, is everyone ok with the synchronous focus bounce?
sarah: the current wording is a little vague, there is feedback to be specific now, and if we need to change it we can change it in the future
tyler: webkit implemented what jamie suggested here
tyler: so I think we are good
jcraig: to clarify what Sarah is pointing at here
jcraig: more like this might need to change later..... that could be a blocker, but we think we can handle this. The goal is to get it into users hands, and workout kinks when we find them
jcraig: the major concern is not making a web compat issue does the line
Jacques: I want to clarify chrome and firefox have shipped this not behind a flag
Jacques: I think it's not a big deal to change it compared to most web APIs
tyler: it's still behind a flag
Jacques: aria-actions in any form, I haven't implemented the focus bouncing, I haven't looked at this but if firefox and webkit are good I'm good
pkra: editorial request, can we merge something, I'm talking to people in the spec but there is nothing to point to
jcraig: sounds like we have implementation, we have tests in the browsers, probably not a way to test in WPT yet
jamesn: I think we can merge stuff.... but not into 1.3 draft??
Daniel: if we want to merge, I need to freeze a branch, because we are not in a position to include this in ARIA 1.3...
Daniel: if we want this in the editors draft, we need to freeze 1.3
Matt_King: This morning I added more comments, Sarah if you have seen them, there are a few places where the language needs to cleaned up
sarah: your suggestions looked good, I think they are all editorial
"accessibility descendant" in presentational role inheritance and other concerns
spectranaut_: did someone say they would write tests..........? <silence>
pkra: jcraig pointed me to some tests
pkra: I'm starting to want to do th is
pkra: the best I can come up with is canvas, because the html canvas stuff coming out, audio/video, the test -- if they are not blocked by html-aria (it is prevented on a lot of elements, although browsers don't always follow that)
pkra: there is a comment from axe with their investigations, which is just lists and tables
pkra: conclusion: only happens for list and tables.
pkra: so the general case doesn't work, and is SVG it doesn't make any sense.
pkra: so I think we need to update this old spec language
pkra: so I'll draft something to update the langauge
Questions about the toolbar role
pkra: there are two problems: consistency in teh spec, and the question sarah raised, should we have this it's weird
aardrian: I think it's not a must. there can be sufficient context
<jamesn> +1 ro aardrian
<jamesn> S/ro/to/
Matt_King: I think it should be a should
Matt_King: the things you might have seen.... it is really difficult when there are multiple toolbars, and toolbars side by side, and they have difference scope on what they are working on . I find the labels really helpful, even if they are noisey, I wouldn't be able to use without the labels
pkra: I think obviously WCAG will kick in and require them, there is plenty of language to suggest you should label things to make them clear. I could get rid of should but understand if you want to keep it
Matt_King: when we say it's a should in the APG, naming guidance by role, it should be backed by ARIA
pkra: I'm worried that if should is there, then authors might blindly add thigns
jamesn: or the AI reads the spec
sarah: to Matt's point, there are places where it's help to be a should, but the thing is there are cases where you SHOULDN'T
jamesn: you could add something more contextual in there
Matt_King: I'm happy to help write a sentence like that
pkra: we could use a good sentence/standard language to use in these situaitons
<sarah> spectranaut_ I don't remember being that emphatic about thinking there are toolbars that shouldn't have names :D
Matt_King: we might have a sentence like it in the APG
RESOLUTION: Remove authors MUST label when multiple toolbars, and propose language for author SHOULD statement.