Meeting minutes
New Issue Triage
spectranaut_: aria#2374 is editorial for editors
… html-aam#569
scott: from last html-aam PR that needed porting to monorepo.
… jcraig had made a point about title in combination with description attributes
… I thought we should track this.
spectranaut_: should we agenda it?
scott: yes. I don't have time right now.
jcraig: I think all the implementations do not throw away title but shoehorn it somewhere.
… might need an implementor to look through engines and gather what's there in practice.
… I can help finding the locations.
spectranaut_: let's put that in the issue comments.
… maybe even good first issue
scott: looking at the tree in, say, chrome, can help - seeing how it's ignored. It's more about figuring out how this could be use
smockle: should this be in aria-at?
thanks smockle!
spectranaut_: maybe. but let's start by researching this.
… next html #568
scott: with options in the select, you can use the label attribute or text as child.
… also for customized select.
… label will override what's in the option.
… but in a datalist, you can have an option, do things similarly but you can have both and some browsers will expose both.
… in that case, browsers might expose second line as description
… some ignore label completely.
… feels like we should standardize to ensure no content is lost.
spectranaut_: ok, sounds like this needs some research.
siri: what's the difference with datalist?
scott: datalist associates a text input with a popup of options.
… whereas the alternative is listbox like.
… we could discuss this outside triage
siri: thanks.
spectranaut_: this needs research.
scotto: I've done the research but just don't have the time.
New PR Triage
spectranaut_: aria #2373 for html-aam
scott: that's the moved PR
… this needs to be re-reviewed for mono-repo merge.
spectranaut_: anyone besides jamesn and myself?
melsumner: I'll do it.
jcraig: I'll take a look.
spectranaut_: aria#2371 for aria spec
scott: this is for an older discussion to allow US spelling
spectranaut_: it's not editorial, right?
scott: don't know. It changes a note. But it's a MUST Not for authors.
jcraig: it aligns with an WPT we have.
… you can add jcraig and rahim
scott: the only question might be in which one should be favored when both are present. I don't have strong opinions but included a decision.
… but if other options are preferred, e.g., dom rder
jcraig: let's not let dom order override a valid property with an invalid one
spectranaut_: last one is editorial. I'll take it on
WPT Open PRs
spectranaut_: anything we need to take a look at?
… nope.
Deep Dive planning
spectranaut_: we had set whitespace deep dive last week.
melsumner: yes, Dec 5. All of the issues in the whitespace project.
… open question was the time slot.
… either the usual hour before the regular meeting or at the regular meeting.
… I don't have a preference myself.
spectranaut_: and we'll have a meeting in the afternoon next week for AUS participation.
… does this need James Teh?
melsumner: implementors would be important so that would be fine.
jcraig: I won't make it but will ping Rahim.
melsumner: I can only do Dec 5 so otherwise we do it in January.
spectranaut_: would afternoon work?
melsumner: yes.
spectranaut_: great. I'll ping Jamie.
Feature: Braille only regions for student testing
aaronlev: we got feedback from Markku.
jcraig: I had pinged him as well.
aaronlev: we now have some more information from them. They have regions with complex markup so braille props would be insufficient.
<melsumner> thank you jcraig for confirming
aaronlev: that seems like a reason.
… we should see if this is important enough for us to add such a platform.
jcraig: I've pinged stakeholders on our end. This is weird one. It has some risk, reducing accessibility intentionally.
… I see the point but it's a tough one.
aaronlev: had some more communication. there might be other ways to do this. Right now, JAWS does this by looking into the class name. The QTI group has discussed aligning testing people around this.
jcraig: there's always such a risk with this. With the braille props, people immediately wanted to use this. But my gut reaction is: if you have to ask, you shouldn't use this.
… maybe we need something separate. Akin to dpub-aria. A testing one, maybe implemented in a way that won't cause problems on the open web.
… somehow limiting to testing apps or testing mode. ideas like that.
aaronlev: I'd be in favor of doing something via QTI industry agreement.
… it's so niche, that feels good. Otherwise the spec just grows with these niche features.
jcraig: and JAWS does this?
aaronlev: yes, we're moving away from exposing DOM attributes. But class seems unlikely due to history.
jcraig: it feels microformats like.
spectranaut_: so we will wait for feedback.
Stop automatically exposing details relation for figure -> figcaption
aaronlev: at some point we decided to expose detail relationship for figures. JAWS feedback was that it became very verbose on some pages. This caused JAWS to disable details announcements but users won't turn it on.
… for figure and figcaption they are so close to each other, it seems unnecessary.
<spectranaut_> PR: w3c/
scott: we had updated the PR for this. We just need to accept the PR.
spectranaut_: right. the PR is waiting for reviews. Please take a look.
scott: the reason for the original change was from previous feedback that getting accname from figcaption was too verbose.
… the figcaption would repeat this, the information was too verbose. We decided on details but implementation of that was not clear at that point.
… then as per this feedback, then the group adjusted the PR again.
… since chromium was I think the only engine to implement this, this PR doesn't have a lot of impact on engines.
… now we have the roles to be exposed.
spectranaut_: thanks, scott!
scott: due to the mono-repo move, this has to be re-reviewed.
spectranaut_: sometimes it helps to open an issue on firefox.
jcraig: I'll take a look
[AriaNotify] Is ariaNotify the best name for the new notification API?
alisonmaher: this revisits TPAC discussion.
… we had discussed the name.
… jamie and aaron had good points on keeping the name
… now would like to move this forward
spectranaut_: there do not seem to be objections, so this seems to be a go.
alisonmaher: great!
w3c/aria#2362
dmontalvo: there's a PR from jcraig on core-aam. We wanted to get this for snapshot. Would be good if people can take a look.
jcraig: I feel like a snapshot should not have a TBD in it.
… if we shipped a feature on a single system, it seems shipping TBDs for all others is not good.
… but perhaps the question is if we want to do this, or say it's at risk.
… that's why I think this is important
spectranaut_: it seems this one is actively implemented in blink. webkit has an open bug as well.
jcraig: webkit would come when voiceover support can be implemented.
… until that time it's speculative.
… so I didn't want to file a bug on gecko.
spectranaut_: so since it's unclear if this will be implemented on mac, I wonder if we should not merge this before the snapshot.
jcraig: then make a similar PR to pull it out on the aria end?
… we're not opposed to it, it's just low-priority. I'd suggest merging this for snapshot. Then we can discuss remaining issues, like the can-i-use like listing.
<spectranaut_> ?
jcraig: but for new features, I wonder what the process should be.
… e.g. label synonyms is only in VO right now.
spectranaut_: ok, landing this on core-aam seems relatively low-risk.
… browser can expose it, VO can pick it up eventually but it doesn't have a negative impact.
jcraig: would we want a note in the ARIA spec that this is not supported across all ATs?
cynthia: WCAG used to have an at risk marker.
jcraig: that's more for when we don't have 2 platforms and AT implementations.
… so at risk seems incorret.
sarah: there's a lot of stuff in ARIA that has support deficits.
… so this seems like a lot of work if we did it for the whole spec.
… if we only do it moving forward, then this might cause confusion for older stuff.
… doing all of it is a very big problem.
jcraig: that's a good point.
cynthia: it is a lot of work but keeping track of things in PRs is, too.
… wrapping up on what's going on and coming up in ARIA is hard.
… so having things in the spec with status, that would be really good.
spectranaut_: dmontalvo, what's the deadline for the snapshot?
dmontalvo: Nov 22 would be ideal.
… no problem if we miss a few weeks.
spectranaut_: jcraig could you propose a note that matches your concern?
jcraig: let's merge this PR and wait on the note for the spec.
… I agree with sarah that there are bigger gaps and it's a larger projects.
… e.g. I was looking at caniuse for ARIA and it has just 1 aria feature entry with "partial"
… if we could start documenting all aria features on caniuse, we could cross-references.
… that would include notes for browser and ATs.
cynthia: there's also the baseline people who might be interested.
<cyns> https://
spectranaut_: ok, I'll make an issue on gecko before merging.
jcraig: I don't want to give them a busy bug.
… add a note on the discussion if possible.