Meeting minutes
New Issue Triage
jamesn: html-aam#475
… why are b and s mapped but i is not
jcraig: came up while writing automated tests for html-aam
… this felt overlooked back when generic vs non-generic was discussed.
jamens: personally, feel that b should not be mapped to strong. s makes more sense to me, very visible, very much used for it. bold seems less problematic.
marioB: feel like italic should be generic.
jcraig: in my experience screenreaders pay attention to style more than tags.
jamesn: put on agenda or make proposal?
jcraig: was hoping scott would respond.
james: assign to scotto then.
… next html-aam#474
jcraig: I filed it because screenreaders ignore it but when writing tests I noticed that they're not exposed either.
… as spectranaut pointed out, it would mean changes in most browsers. So perhaps aligning spec to existing behaviore seems more appropriate.
jamesn: some editorial ones - skip
… html-aam#473
… any takers?
jcraig: I think it's related to an issue I filed about windows vs mac.
… I'll take it.
jamesn: next aria#1917 , sarah takes it.
… aria#1916 continuation of PR from last week.
New PR Triage
jamesn: aria 1919, editorial pkra has reviewed it. seems ready
pkra: yes. just left it because spotted an AT SHOULD
jamesn: discussing AT statements with spectranaut.
cyns: would like to discuss this more.
jamesn: at F2F? we have time
cyns: yes!
spectranaut: will add it.
May F2F
jamesn: please review agenda. if you want to add or move items, please let us know.
jcraig: I had requested WPT to be at end of first day so I could demo and optionally do a work session with people who are available, so that we have time the next day in between things to discuss it.
jamesn: we were hoping to split it to avoid overload.
… happy to move it.
spectranaut: we put live regions at end so that James Teh can join.
jamesn: James should be ok with anything after lunch.
spectranaut: sounds good.
jamesn: fyi Thursday should have an office happy hour that we might be able to join.
doug: would happy to run live region session.
jamesn: that would be awesome.
doug: working on notification api.
… the survey we had seemed to have a lot of points due to implementations issues.
… not sure how that could be improved
jamesn: w3c doesn't really address it.
doug: right. but hopefully we can provide guidance to improve things.
cyns: would like to push the needle a bit here.
jcraig: also very hard to test. took us 10 years from ARIA to get testable implementations
jamesn: many of our specs unnecessarily complicate due to weird edge cases. I'm hoping notification api can avoid the pitfalls we now know.
cyns: a lot of complexity is from working around AT bugs rather than fixing them.
jcraig: and author bugs. we have a setting to disable live regions because authors use them so poorly sometimes.
jamesn: we should stop doing that as a community.
… maybe another F2F topic.
jcraig: after happy hour ;-)
doug: my background is windows so I'm hoping to improve connection with other OS ATs.
Consider adding a 'header' and 'footer' role
jamesn: scotto not here.
marioB: there are very good semantics here. seems a shame to lose it when it's not a child to body.
jamesn: so this is for non-landmark cases.
… wondering if they are really header or footers or just bad authoring.
pkra: I can see some use cases in complex document content like scientific figures.
cyns: are there OS level features that this could map to?
spectranaut: scotto might know.
jamesn: doc-pageheader is more about repetive content
jcraig: most epub readers don't repeat them in the flow. They can be reached by users but not exposed by default.
… I know there are browser based epub readers, maybe they'd need it.
… so in dpub those are fairly safe. but header and footer that might be skipped would be bad in, say, an article.
<jcraig> https://
pkra: ah, ok, thought it wasn't about repeating content. we also had an older discussion around that on dpub, I think.
… I understood the issue to be about complex fragments
jamesn: what benefit for users could these give?
jcraigt: could help when landing on them. looks like some APIs map them already.
jamesn: I suspec they're not exposed because they're used wrong too much already. In that case we would not really add something useful. E.g., header usually has a heading so doesn't need exposing as a header, too.
jcraig: scotto suggested name from auhtor.
pkra: maybe revisit with scotto?
jamesn: right.
Windows/Mac differences in presentation of some HTML-AAM implicit roles
jcraig: tied to automated role tests I'm working on.
… two mappings for select element.
… single vs multiple. no discrepancy for multiple. but as a single, it differs across platforms.
… windows is a kind-of combobox
… on mac something we would call a popup button.
… some type ahead but not a text field like combobox.
… it's really a UI platform expectation
… somewhat similarly: number input. reversed, allows typing in but has stepper buttons.
… again somewhat different. on mac, a sort of textfields with additional functionality.
… jawstest claimed there was some difference but I didn't fully grok it.
… I wasn't sure how to reconcile it.
… maybe we could normalize it. But e.g. changing to combobox on mac could end up being confusing to mac users.
siri: re combobox being something to type in. In APG, we changed our examples to have select-only combobox.
<jamesn> https://
jcraig: good to know!
… I would still not expect users on mac to expect combobox for this.
jamesn: a bit of a fundamental issue. we can't switch aria patterns based platform.
… but this is about native select elements.
… do we all agree that the aria patterns should be exposed the same across all platforms?
jcraig: not sure. Yes, it's about native select. That it's related is also important.
… I would expect, if it works exactly like the native control, then I'd expect users to have it exposed the same way as the native control.
jamesn: can VO make the pattern work like the native control?
… the exposed behavior does not have to be the same as the internal role, no?
jcraig: it would be the first of this kind, I think.
jamesn: but for non-English, there's already a change, no?
jcraig: yes, still.
jamesn: in APG there used to be a select-only pattern that was not enough windows-like. This was confusing to windows users.
… I'm slightly concerned that it would be a big project to do something similar, the other way around.
ben: what would a possible change be?
jcraig: I haven't fully dived into it yet. Was hoping for the discussion to help. With precendence, I feel like it should be exposed as a popup. I'll need to think more about it though.
ben: looking at windows APIs, it fits well.
jcraig: good point, will look deeper from that angle.
ben: aside, combobox with textfield on mobile could use some attention; we all have a similar problem.
jcraig: add this please.
RRS agent, make minutes
RRS agent: make minutes
damn: )
RRSagent: make minutes