Meeting minutes
New Issue Triage
<jamesn> https://
https://
jamesn: editorial, don't need to worry, duplicate
jamesn: peter can you close?
peter: I'll leave open, the other is closed
https://
jamesn: I think there isn't anything air related in this.. it's an authoring question... lets move to APG?
jamesn: moving
New PR Triage
<jamesn> https://
Deep Dive planning
https://
jamesn: next week, no deep dive, the week after that is sarah's, the next open is first week of February
jamesn: I'll schedule sarah's deep dive in the calendar soon, related to secondary actions on things
Inconsistency between native and ARIA listboxes when implicit aria-selected is provided
<jamesn> https://
joanie: I don't mind if this is closed.... orca doesn't this do this
joanie: I'm a fan of saying the author needs to set aria-selected
joanie: I don't think we have to change the spec, because the spec says "should" not must
spec: If a user agent provides an implicit aria-selected value for an option, the value SHOULD be true if the option has DOM focus or the listbox has DOM focus and the option is referenced by aria-activedescendant. Otherwise, if a user agent provides an implicit aria-selected value for an option, the value SHOULD be false.
joanie: I think all of aaron's suggestions work. does the working group really think it should be this way?
joanie: sarah says this just doesn't happen in the wild.... but maybe a use case is if you have a list box with three items, and if you tab in a select box and move to item "red", then move focus to submit, red will be selected
joanie: but the spec says if the thing is not focused it no longer has a value
joanie: but maybe sarah's point is more imporant, because it will never happen in practice
aaron: I think chrome adheres to aria-activedescendant when there is no aria-selected
aaron: I asked Dominic why we send aria-activedescendant when you are no longer on a widget, the reason is because of this, we might need that info later
jamesn: if it is a should in the spec but we don't agree with it, then we should change it
joanie: maybe the second is the easiest
aaronlev: I think aria-activedescedant on a single select should be used as aria-selected
jamesn: so we should remove the "dom focus" part of that original paragraph
aaronlev: I think that looks right, but we need to run it by the Matt Kings of the world
bryan: if you are using jaws in a certain mode, even though focus isn't set in the listbox, it will announce what the selected option is. But if aria-selected is not set it will not say that something is selected.
bryan: I don't know if this is a behavior issue or something that needs to be speced out
siri: I like the option proposed by aaron, I can see aria-activedescendant being used this way... in this case aria-activedescendant and aria-selected will have the same value
aaron: I like the "alternatively" one, without authoring changes
james: would you be openning a PR with that?
jamesn: would anyone like to open a PR to allow aria-activedescendant being used?
melsumne_: actually I more ok with this than my comment btw
carmacleod: I'll make the PR
Clarify usage of aria-haspopup
<jamesn> https://
jamesn: we need to talk more before a proposal, says the minutes from the last meeting
bryan: i'll look at it
ARIA 1.3 - are we ready for FPWD - what is remaining?
jamesn: what needs to be done in order to move it forward and get the first public working draft out?
jamesn: there isn't anything in stable other than bug fixes, i believe
<pkra> https://
peter: i did update that one issue with the bare minimum ^
<jamesn> https://
jamesn: these are the main features we are considering in 1.3
jamesn: what we need to do in order to get things into the spec is to have implementations
jamesn: and text in APG for how to use these new features
jamesn: the first one we can ignore
jamesn: the rest of them, aria-rowindextext and aria-columnindextext
we need APG for these
jamesn: browser implementations for aria-description?
aaron: something missing from apple, and firefox is missing a small thing, but it's mostly there
jamesn: there is no spec text for core-aam
jamesn: for mark, aria-description, etc... is it n core-aam and my wiki is out of date?
joanie: i think os
jamesn: I need to update the wiki for these PRs on the core-aam editor draft
<aaronlev> mark, suggestion, comment, insertion, deletion
<aaronlev> aria-description
jamesn: the main things that is missing for all of these is the missing authoring guidance
jamesn: aaron you have examples, correct?
aaronlev: i have a single document
<aaronlev> jcraig: aria-description still says AXHelp in CORE-AAM, which I believe is only correct < OSX 11
spectranaut: I can take a look at these, I need some help understanding exactly what needs to be done
jamesn: I can work with you and assign issues
<aaronlev> Here are primitive annotation examples: https://
jamesn: we need something similar for braille properties
jamesn: my gut feel is that the APG should strongly dissuade people from using them
joanie: I'm still not clear on what people would like me to do...
jamesn: we haven't published 1.2
jamesn: core-aam shouldn't hold up things, since we are moving towards evergreen anyway
jamesn: back to the braille ones, maybe we just need to use similar language in the APG
peter: there is another thing we can do, there is an open issue about having extra notes on things int he aria spec that are worse than others.
peter: maybe james brought this up, maybe we should do that in 1.3. add a note that says you should generally not do this. I'm happy to add APG for the braille things.
peter: the examples are too simple, and we shouldn't use these simple examples, and we should point to the APG
peter: in the APG a reasonable, complicated example
<jamesn> <button aria-braillelabel="****">
<jamesn> <img alt="4 stars" src="images/stars.jpg">
<jamesn> </button>
<aaronlev> I wrote an article that explains why ARIA is so hard to get right / test: https://
<aaronlev> it's a good intro for folks not familiar with ARIA
<aaronlev> it's a good intro for folks not familiar with ARIA (I think)
jamesn: we need something different than a note, a different color, for these "warning do not use" notes
peter: we do have something in safari
joanie: firefox you get for free, aria-foo gets exposed
aaronlev: I don't know if we are exposing these properties in chrome but I can look
joanie: orca exposes
<aaronlev> Chrome doesn't support aria-braillefoo yet
peter: can you file and issue against chrome and cc me?
jamesn: we can add this to adding accessible names and description as a "do not use this in relation to that"
jamesn: we don't have an attributes "don't use these" list
jamesn: (unless you really know what you are doing)
<pkra> This was the issue https://
jamesn: should we add it too these sections? should we have good examples of places to use these?
peter: someone will always use it for things it shouldn't be used for
aaron: you will even see "aria-label" when there is an alt text
peter: I will write things for APG on this
aaron: once these examples are in, we can merge these things into 1.3, and move onto the 1.3 working draft
chris lane:
chris lane: at vm ware, we a have a note to not use aria-modal without using the rest of the application needs to be inert. I couldn't not get my stakeholders to follow that, they used aria-modal anyway. it does say that it is bad, but I couldn't make the case well enough
chris lane: maybe we need an example of why it is bad
chris lane: otherwise people might be resistant?
jamesn: in APG we don't generally give bad examples
chris lane: maybe I should write a bug, I need a stronger user impact
chris lane: maybe I'll write up an issue, I'll do that
jamesn: cool
RRSAgent: make minutes