Meeting minutes
pkra: about the abbr elements
spectranaut_: also the question on IDs
pkra: and also proraming vs programming
<spectranaut_> and also there is a PR for the abbreviate change: w3c/
pkra: I'm pretty bearish about these changes.
scotto: this seems more like a W3C spec issue
… would make ARIA almost an outlier
… I'm not a fan of title attribute
… but wouldn't want to drop abbr entirely
… sometimes people actually use them.
… feels strange to rip them out just because there's longstanding issues with screenreaders
spectranaut_: this is just refering to abbr?
scotto: yes.
spectranaut_: and consistent in other specs?
scotto: yes, I would claim that.
… I think it's often auto-generated
… spec-ref generates this, I think.
pkra: I feel like they're not too many for the length of the spec but crowded in the introduction.
… dropping them everywhere would make it difficult to find the context further down in the spec.
… and people don't read sequentially
… but in the intro it's crowded.
spectranaut_: so a possible outcome is cleaning up intro?
pkra: yes. define it on first use in a section seems fine. we do that in spec text for xref as well.
spectranaut_: scotto ok?
scotto: yes. AFAIK it's mainly a non-default JAWS behavior.
dmontalvo: VoiceOver has also a particular behavior that can be annoying.
… but it's also a screenreader behavior and isn't generally a problem
scotto: whenever we can do it, we'd still have respec injection to deal with. And dealing with that would make it inconsistent compared to other specs.
spectranaut_: so we suggest to only make changes to introduction after first use?
scotto: I'd be fine but I'm also ok to not do anything.
pkra: I'd +1
scotto: would prefer not make it inconsistent.
spectranaut_: ok, let's close this then
scotto: let's talk at the meeting maybe.
pkra: I can write a few words on the issue.
spectranaut_: back to the IDs
… seems obvious no
pkra: yes.
scotto: yes, we should make it consistent going forward but not change anything right now
pkra: let's make issue.
scotto: yeah, we'd have to keep track of custom spans with IDs
dmontalvo: right, we have that in accname and it's painful.
pkra: that was a good fix and worth the pain. this doesn't seem that way.
pkra: then there was the specific ID
… how did others feel?
dmontalvo: felt the same.
pkra: then there's spelling of pogramming
… feels like historic
spectranaut_: we should be consistent though.
<spectranaut_> w3c/
spectranaut_: on the IDs, we have some relative consistencies. core-aam has two different styles
[continue] aria-common #109 remove/replace aria-wg-active.md and
pkra: dmontalvo had done a PR
dmontalvo: the automatic preview failed but the manual one should render
… this of course need to go elsewhere.
spectranaut_: goes into common>
dmontalvo: yes.
pkra: looks good.
spectranaut_: we talked about whether to include it at all.
dmontalvo: right. now that we know we can do it, we can make a decision.
… do we want to make a decision compared to previous section.
… "active" is really the previous section.
pkra: just dropping "active" maybe?
spectranaut_: yeah, not bad.
pkra: I'm also ok with just dropping it.
dmontalvo: this might be compulsory.
spectranaut_: and people show up rarely but contribute.
… next steps?
… making a PR to all specs and aria-common?
dmontalvo: right. the JS into common, the markup in each spec.
… wait until aria.js is done
pkra: we can skip the rest, I think
scotto: html-aam has a lot of old PRs
… some just need updates.
… some lack reviews
… and then there's the process.
… I'm unclear when I can merge things
… e.g., getting WPT or filling browser issues
… sometimes there seems consensus but then massive comment comes in which throws a wrench into things.
… especially the last few weeks, I couldn't be around and stuff doesn't get done.
… we need another editor.
… feels like entire ARIA meetings are about html-aam.
spectranaut_: thank you for voicing that.
… initial thoughts: brainstorm a better process
… in html specs specifically
… also, we have the new process. we can try to refine it to make sure it makes sense.
… I would be ready to sit down for that.
… process needs to not just ensure a good spec but serve us as a group
… the unsolved problem of html-aam: review means review by implementers?
scotto: yes, usually.
… I understand that that's not always possible.
… but we need a check-in for PR status.
… it's not just html-aam
spectranaut_: yes, that's a change James & I can do more actively
scotto: I usually write the change
… but then also the individual bugs.
… but for new content, it's a lot, too.
… feels like there's more work for html-related changes than just ARIA
… every single core-aam and html-aam change needs full suite of tests.
spectranaut_: agreed.
scotto: if WPT were done by somebody else, that would be good.
… e.g., figcaption tests. I can put them into the issue but don't have time to put them into WPT proper.
spectranaut_: could it help to have backlog issues "test for this change"?
… I would assign myself for these.
scotto: could I do this after merge?
… could we make a column for tests?
spectranaut_: that's a good idea.
… and we can tune the process if there are more ideas
pkra: but we still need additional editor?
spectranaut_: right.
scotto: dividing items would help very much. suitable chunks seem easy.
scotto: separate item - what is the status of aria-in-html?
… end of year we talked about bringing it into ARIA WG
dmontalvo: technically would be part of new charter. after extension that would be ~August.
scotto: I'd like to avoid web apps WG dropping it before it's with ARIA WG.
dmontalvo: yes, there's a small risk of that.
… I'll check if we can start working on it.