Meeting minutes
New PR Triage
jamesn: first is editorial. do we have reviewers?
adrian: I'll take it
keith: me too
jamesn: next ios mapping rows
scott: it's TBD right now but wanted to get it in there so we can chip away.
… the big lift will be to do a matching change on core-aam
spectranaut_: should I start a PR?
scott: maybe one PR
jamesn: several interesting question. How to set an example? Where are we getting the information this kind of info from?
scott: rahim had been discussing this internally, that's where we started
jamesn: how can we verify?
scott: good question. Perhaps their inspector tool might be able to verify.
jamesn: ok. what do we do about android?
scott: needs someone from Android to step up like Apple did.
cynth: I may have someone to bring in. Will check.
WPT Open PRs
jamesn: There's just one new one.
scott: that just needs reviews and merge.
Deep Dive planning
jamesn: we only have the table ones. We wanted to schedule this for July.
giacomo-petri: I think Keith wanted to compare algorithms before we do this?
keith: right. I've tried to build a kind of spec for it. It's a bit horrible.
… there are some significant discrepancies between engines.
… but perhaps it will still do some good.
jamesn: should we schedule it?
keith: let me finish the spec. It's a bit like a fourth implementation since it deviates from engines.
New Issue Triage
jamesn: first is editorial, for editors meeting.
… next html-aam 587. Sounds like one for Rahim.
scott: yes, he already started on it.
… Steve had tried to do something way back when. Rahim will try to make a better section of it.
jamesn: next html-aam #586.
scott: this one tries to resolve "scoped to body" vagueness in the spec.
… for this.
… this should make things more consistent.
jamesn: next html-aam 585
… on the agenda.
TPAC Timing preferences & what groups do we need meetings with?
jamesn: we have to decide which days we want to meet. Chairs prefer early in the week.
… we try not to meet on Friday.
… ARIA on Mon&Tue, other meetings Wed&Thu is our preference.
keith: would like to avoid conflicts with WHATWG and CSSWG.
jamesn: right. CSSWG meets all week so that's usually not feasible.
… but we can try our best.
… other topic: which groups do we want to meet and what about?
… it's a short timeline: please get us something by the end of the week.
… just a subject and time estimate.
<aardrian> Tables. Put me down to talk about tables.
jamesn: group-aria-chairs@... will get it to the chairs.
What to do about computed roles for table?
keith: tldr: chrome will give you non-standard roles when it detects a layout table.
… that's helpful for tests but it's non-standard. I presume it's a webdriver specific behavior.
… webkit gives an empty string, which I presume means presentation.
… firefox always does table and then attributes. That's also non-standard but all ATs use it.
… I think it would be great to have a role to test. But that also obviously seems problematic.
… or talk to webdriver people to make things consistent there.
adrian: beyond engines, I know that JAWS has its own heuristics that are independent of user agents.
keith: that's very interesting. I admit I'm interested in it from the browser side.
adrian: when we say AT, we're really only talking about screenreaders, since they are the AT that does something here.
… since they've done things before browsers did, it would be good to contact them
keith: I don't disagree.
adrian: caveat, I havent' tested if they have happened to align with user agents.
keith: right, probably not though.
scott: are you looking for agreement to write spec language for layout tables or are you assuming that the heuristics are correct or not?
keith: I don't really want to focus on the heuristics themselves. In this issue, I want to focus on what they return.
… I've written a bit of the spec that returns either table or presentation.
… if we had layout tables, we could map that to various APIs via AAMs.
… I think it gets awkward in the spec. If the computed role return presentation, then it has to combine the information
scott: right. I like the idea to have a layout table role. I would suggest something like the html-* roles we have already, only in HTML.
jamesn: couple of thoughts. If role=presentation is on the table, then I feel that should stick.
… don't want to mess with that.
… I left a comment on JAWS behavior.
… like pixel size of cells.
… basically "really weird stuff".
keith: browsers don't that but they check e.g. borders and striping.
jamesn: nowadays some things should help (e.g., headers should help)
… I'm not sure if we should spend too much time trying to fix ancient history rather than modern standards.
keith: right. I was hoping to slowly chip away at that until tables are just tables.
jamesn: right. Still, I think developers have a good way to mark things as layout - presentation / none.
keith: right. still, people trip over layout tables.
jamesn: so they're building data tables that browsers turn into layout?
keith: yes.
… e.g. first row TH with too few data that webkit will make it a layout table.
jamesn: thanks, that helps a lot to understand the purpose here. Sounds very good.
keith: scott's comment re html-* roles.
… then it would still be a table?
scott: the point of html-* roles, it leaves it up to browsers to expose those as they like. But it gives us a consistent WPT surface.
keith: sounds good.
… I see html-video etc. That makes sense.
… I think I have a good direction to follow.
… should we schedule the deep dive?
… maybe July 18?
jamesn: perfect.