Meeting minutes
New Issue Triage
jamesn: 2140 on aria
jamesn: any comments on this...?
jcraig: this sounds editorial. its allowed in other areas, I think its a bug in that one sentence
aardrian: I could do this
jamesn: w3c/
jcraig: we are going to remove "orphan" role tests to some tests to a tentative file... this is not something that is actually speced in ARIA
jcraig: orphan tests are gridcells that are not in a row or table
jcraig: though these are author errors, we do not make clear what the user agent should return in these scenarios
jcraig: should it be left to implementation detail? there are differences in the implementations
jcraig: the aria working group should decide what to do. this might have html-aam downstream work
jamesn: should we agenda for further discussion?
jcraig: probably also a deep dive candidate
jamesn: w3c/
<scotto> was only going to comment on the fact that i agree. html aam work. there are already some instances of contextual roles exactly about orphaned content
jamesn: should we leave this going in discussion between scott and james teh?
scotto: one of the reasons this is coming up because we keep punting association list down the road
jamesn: yeah... ok... well.. should we talk about again?
scotto: doesn't need a deep dive. I think last we talked about it, detailed lists should just be lists. whether we do role description, I'm unsure. but we should finish discussion
jamesn: agenda'd
jamesn: w3c/
jamesn: should we agenda?
jcraig: yeah I think so
jcraig: dominic should be there for the discussion
jamesn: w3c/
scotto: I filled this for myself
scotto: to see if anything needs to be mentioned in the naming steps.. finally putting together wpt for minimal role stuff
scotto: then I saw this should statement
scotto: how is naming handled for things that have draggable attribute?
adam: does putting draggable make it focusable?
jcraig: no, it doesn't even make it draggable
jcraig: complications with that are why we dropped the aria properties
jamesn: w3c/
scotto: val assigned her self to make platform bugs, we should do any more work on this until those things land
New PR Triage
jamesn: w3c/
jamesn: two approving PRs, I think we can merge
WPT Open PRs
jcraig: I'm working with anne on: web-platform-tests/
Adam_Page: this one is still draft: web-platform-tests/
<scotto> did i do something wrong for web-platform-tests/
jcraig: I'll review this one and merge web-platform-tests/
jcraig: unless the removed tests should be put in tentative
jamesn: they look fine to remove to me
Deep Dive planning
jamesn: nothing to schedule for next week or following week
Daylight savings time
jamesn: if you are outside of the US and canada, the meeting time will shift
for the time for the next week, if you don't have daylight savings time
Add `nameFrom: heading` steps to computation after spec addition ARIA PR #1860 is reviewed.
to discuss this comment: w3c/
jcraig: to describe briefly, tthe first heading is expected to contribute to the name from authors probably
jcraig: but depth first search will slow down name computation
jcraig: I think the user would notice on all of these roles
jcraig: there is another search, iterative deepening first search
jcraig: this will work most of the time, but there are examples which really don't make sense
jcraig: see scott's examples
jcraig: this may or may not be an edge case
jcraig: we need consensus from wg and implementers because of the performance hit
scotto: the issue is that I understand what james is saying, I don't want a performance hit, but I can't say these are edge cases, I see these patterns everywhere
scotto: I found three sites that would have unexpected headings for the name of the article
scotto: they are using the mark up pattern that html says they should use
jcraig: they are using the hgroup?
scotto: some people are using the hgroup
jcraig: on a lot of sites there are lots of extraneous divs
scotto: I would expect divs without roles to be ignored
scotto: but what about div tab index -1?
jcraig: I would need verify but I don't think that would improve the performance
jcraig: deep vs breadth is the critical part, parsing the nodes and ignoring them won't help
jcraig: the critical blockers, we need to hear from chromium and gecko
jcraig: if they come back and say "eh it's not much of a problem", then I'll dig deeper into webkit and get some numbers
jamesn: it seems like the alternative proposal has too many weird consequences... with unexpected names occurring frequently. didn't apple already implement something similar for articles?
jcraig: I filled the orig bug a few years ago, but i said the spec should be more permissive in the way we choose the name. voiceover was naming things based on what it knew was a heading inside. webkit obscured some extraneous divs. voiceover's search was fast enough
jcraig: sounds like something you don't want, iterative deepening, so maybe this is a choice between standard depth first search or scrapping name from heading?
jamesn: you are doing something with html according to specification, and you will get something unexpected
jcraig: I'll change the PR to use deep first search, and then it will unblock implementaitons
jcraig: then we can investigate the performance cost
jcraig: unless the web engines are conscious about potential perf costs, the change can include a way to measure the change
jamesn: I'm curious about.. aren't we calculating the accname for all the elements anyway?
jcraig: we don't compute the name until we land on it
jamesn: is that why it takes so long for the acc tree to come up?
jcraig: in the dev tools, it takes a while because it's spinning up the acc tree and doing additional calls
jcraig: when you land on a article, you have to go through the WHOLE subtree to rule out name from heading
jcraig: if there is no heading that will take a while
scotto: contextual roles for header/footer/aside, etc
scotto: talking to aaron lev, aaron was saying that if we spec this to be based on the acc tree rather than the dom nodes, it would be more performant
scotto: that is where I was coming from, if this calculated in the acc tree instead of the dom tree
jcraig: that is a good idea, but because we don't have a standard accessibility tree between browsers it might lead to difference. I don't think we could implement it yet reliably
jcraig: if you are talking to him can you post the comment?
scotto: I'll saw what I remembered, and I'll cc him in
jamesn: I know this is something that might not want to do because it is hard to explain, seems like 99% of our use case or more would be covered if we did depth first search of only 2 deep?
jcraig: maybe 75%
jcraig: and you add an extra div and it suddenly doesn't work
scotto: and what happens with shadow dom???
Deep Dive planning
ARIAMixin has many integer attributes with string types and uses DOMString? incorrectly
jamesn: is this something we are ever going to do something about?
keithamus: some of the types don't match up.. I'm not sure the risk to make them match up
keithamus: I plan to chip away at this over the next month or so, if we align to the html spec, it would require changes in the browser implementation, which is fine except for compatibility issue. There are certain patterns where developers do feature detection...
keithamus: for anything that isn't enumerated, if you can set it and read it and see whether it is a supported value
keithamus: this needs some careful teasing apart
jcraig: this will break existing web pages, its not editorial
jcraig: there is a web compat risk
jcraig: I handed this off to anne and others because this is a broad discussion
jcraig: we reflected all of these as strings for a few years now... and think.. last year gecko implemented to match. we even have wpt tests for it...? I will have to verify
jcraig: to get these changes in, we will break a lot
jcraig: I don't think we don't have usage information about whether anything will break
keithamus: that is what I was going to div into
keithamus: we incorrectly says "domstring?", there is an editorial change to change from "domstring?" to "domstring"
jcraig: the "?" means nullable?
keithamus: yeah, and "domstring?" must be limited to known values, for eample
keithamus: so we need to tweak it for that. but each one needs to be analyzed
keithamus: this is worth weighing up each change
jcraig: probably it's fine if we change from a nullable to empty string
keithamus: (something about salesforce I didn't catch)
jcraig: I'm fine with domstring? to domstring
jamesn: sounds like you are working on this and I really appreciate, this is an area the group has been lacking in expertise
<keithamus> Salesforce (Nolan Lawson) are concerned about changes to this due to their polyfill, and we don't want to break that.