Meeting minutes
Zakim: next item
New Issue Triage
jamesn, 2 new issues: Accname stable branch, it has a few comments already - if the commenters need help we can get that in the right state.
jamesn, next one is whether aria-labelledby maps to AXDescription or AXTitle. We need James or Rahim to look at this. Can we assign this to you Rahim?
Rahim, sounds good
New PR Triage
jamesn, only one new PR, editorial. Scott if you need help, let us know. Myself or Peter can probably help with how specs link together.
scotto, there's some hardcoded instances, I'm not blocked though
WPT Open PRs
jamesn, only one WPT PR. accname one. People need to review. Waiting on that. Nothing needs doing it seems.
Deep Dive planning
jamesn, do we want to plan deep dives for the rest of the year? Would we like to have an extra meeting to talk about the issues on this list? Or any others?
jamesn, I think we can not do deep dives for the rest of the year, any objections?
F2F in Boston in April?
jamesn, F2F next year, potentially Boston? Can we make this more concrete? Does April in Boston sound reasonable to aim for?
<Adam_Page> yes to April in Boston
<marcelo-paiva> Boston works for me
Cory: Not the first week
<BGaraventa> Possibly for me yes
melsumner, not the second week
<spectranaut_> not the first or second week for me, actually
<marcelo-paiva> Any opportunities to meet at CSUN?
<spectranaut_> actually maybe i could do the second week, end of the second week
jamesn, A core reason for boston is for Scott and Aaron to attend
<spectranaut_> sounds like third week won't work for scott
Matthew: Should we do a poll?
jamesn, do we have a host?
Charter extension
<jaunita_george> +1
jamesn, we will not be able to complete charter before expiry. Proposing a straw poll to supporting a 6 month charter extension; +1 please.
<scotto> +1
<jamesn> +1
<melsumner> +1
<pkra> +1
<spectranaut_> +1
<BGaraventa> +1
<giacomo-petri> +1
<Francis_Storr> +1
<marcelo-paiva> +1
<Matt_King> +1
jamesn, anyone disagree? -1 please.
Rahim, could you explain what the charter extension is?
jamesn, we have 2 year charters to explain what the group is doing. It expires in January, without the charter we cannot publish - so we need to have an active charter. We can extend by 6 months as 2 years is sometimes short. We're working on the new charter but it's not done yet. So we're asking for a 6 month extension.
Rahim, do CGs have charters?
jamesn, no
RESOLUTION: Group approves requesting a charter extension
Rethink definition / term relationship and naming
jamesn, rethink definition term/relationship naming
scotto, Reviewing this for WPT, definition & term rules have shifting over ARIA versions. I'm wondering if the naming of them made sense. When we came up with the definition naming, we stated one could create an association between the two with aria-labelledby; e.g dd could be named by dt. aria-details wasn't used. In aria annotations work, it was
explicitly stated that labelledby shouldn't be used and it should be details. Makes me question naming term & definition more.
scotto, dt & dd kind of go hand in hand with other roles that are prohibited from naming. Overall suggestion is clarify the relationship and prohibit naming.
jamesn, details sounds far more appropriate, definitions can include structured content, where label isn't appropriate.
Matt_King, one q; if you're talking about using definition and term inside/outside a list structure, specifying a relationship between the two isn't a good idea - it'll be a lot of noise. Outside of the context ... but inside the context it would be confusing. There should be guidelines on if you need a relationship at all
scotto, in version past terms were associated with dt and definitions with dd - then we had association lists, explicitly changed the spec so that term is the definition element in html. definition role doesn't have html equivalent any more. So yes Matt, per your point I wouldn't expect them outside a list. Further they shouldn't be used inside a
list anywya
Matt_King, if they're outside the list ... I guess I'd want it to be supported to use .. but not required.It's not clear a realtionship is ordinarily needed. Just allowed.
scotto, anyone using aria-attributes would need to hook them up. If you put them in wildly different places in the dom then make sure there's a details relationship. Otherwise people can figure it out
BGaraventa, part of the challenge - I had to write an internal policy to prohibit aria-details for anything mainly because it's so badly supported. When we created aria-details we talked about being able to navigate into it, like a dialog, you could navigate the contents of the structure, then navigate back out. Right now it focusses the location
and leaves you there; it's confusing because if there is an association, you can get there but you can't get back.
jamesn, Aaron has been working on getting better AT support for details. Please contact Aaron and work with him on that.
scotto, each screen reader has their own keys to navigate to and shift plus those keys sends you back...
jamesn, we want to push people to use aria-details more, by doing so we improve support more. Now it's used for annotations or other things, with more good usage we'll see a push to support it become higher.
Matt_King, I agree with Brian; I know Aaron tried but I almost feel we need to formalize it better. We spent time in the F2F but we need to spend more time on it.
BGaraventa, is there a section that deals with it?
Matt_King, not yet. It's not even on the roadmap for ARIA AT testing.
Matt_King, It feels kind of undefined, Aaron owns it and it's in a Google Doc somewhere. What we don't have is an appropriate venue, form, and process to raise issues related to things like AT behavior; really following them to their conclusion.
jamesn, I agree but that's one of the issues we've always faced. AT folks almost don't want to be involved at that level; the formality of being told what to do. Each conversation needs to be individual rather than group conversations.
Matt_King, we're making good progress on that front... anyway, it's a different topic from term+definition...
jamesn, does anyone think label is the right approach? Or a bad approach?
Matt_King, that's a bad approach
scotto, I'll just make the PR for this and... I just want to verify that we're okay to changing these two. Besides the details relationship, I think that's the change we need here.
Matt_King, I'd support that.
jamesn, I'd agree
Matt_King, related q: do we expect AT to reveal those roles? They're not generic, right?
scotto, support is varied, but it does exist. The roles are announced.
scotto, I'll dig up the file and send it to you for clarity.
Matt_King, I just wonder; maybe they're not used much? Maybe it doesn't matter, but... they feel a little like noise to me. Is the purpose of them in HTML really more for machine parsing or styling? Semantically you usually know what is the term and what is the definition from the content.
scotto, term is the only one that exists as the definition <dfn> element. Definition as the role doesn't exist...
jamesn, why?
scotto, term came first? The <dfn> is to wrap the term, not to wrap the definition
Matt_King, what do you do with the definition?
scotto, that's just a span
Matt_King, why did we not map <dfn> to generic? When we did 1.2?
scotto, term actually is what the <dfn> is. That's where the parity is
Matt_King, oh did we have term in 1.1? Honestly I've never seen it used in practice. If it was generic, <dfn> mapped to generic, we wouldn't have any of these questions.
scotto, that seems like a bigger PR
Matt_King, I ask because the more roles that are announced that are unfamiliar and rarely used - they end up posing more confusion than clarity (my personal experience). When I hear some word announced - "term" - and I don't know why, it can get confusing. I'm just wondering if it's one of those things that it should be in ARIA. Maybe `<dfn>`
should map to generic?
jamesn, if you think that maybe file a new issue?
jamesn, Scott, why not create the PR and in that process we can investigate what it means to deprecate.
scotto, That's fine by me
scotto, we don't need this stuff but we have it. My take is make it better, but if "better" to people is get rid I'm happy
Hierarchy of treeitems per aria level only?
jamesn, Matt you said this was a mapping issue?
Matt_King, you can make a grid by putting aria row level on the rows and aria set size, and the child rows that get shown when you expand a node, they're not nested. They don't even have to be nested in the row group. That's how we've crafted the tree grid - people look at that and say "why can't we do a tree that way". A tree with nesting and no
groups and level/setsize and determine the relationships.
Matt_King, ...we don't require row groups... I'm not sure this is a positive direction to go in. That's my understanding of the issue.
sarah, throwing out a use case: it can be quite difficult to handle inserting groups when you're dynamically rendering tree items. So being able to do this... it's something we just did already and it kind of works, so having it official to work with that use case would be good.
Matt_King, well it sounds like if it works then it doesn't have a problem mapping this correctly.
sarah, we're also doing aria setsize etc on every item so nothing is left to calculate really.
Matt_King, you have aria-expanded on the parent?
sarah, yeah
Matt_King, so is there a relationship of any kind between parent/children? Aria controls wouldn't do anything here?
jamesn, parent might not even exist in dom
sarah, any time a parent group of x tree items might not be in the dom
Matt_King, so if a user is on a tree item and presses left...?
sarah, we handle that
jamesn, so it's non conformant?
Matt_King, any downsides to this? On the validation side? Levels have to be calculated by scripting, not the browser.
Matt_King, I guess there's no way for a checking tool to validate those values are correct?
Matt_King, it would just be a bug that an AT tester might check? If you had aria-level skipping levels or pause/set missing items or some things of that nature - that's something that can only be detected with manual testing?
sarah, that's similar to right now. In a virtualised tree with "correct markup" if you scroll out of view... yeah
Matt_King, oh so if they're out of dom aria-level is the wrong level?
sarah, well its the right level in that it's virtual
Matt_King, but if you didn't specify the browser would calculate the wrong level
Matt_King, required states+properties are ... how would we do this in the characteristics table in the spec? We put them on required states+properties?... how would you do that James?
jamesn, if its in an if, you put it in supportive and add normative text.
Matt_King, so the change would be writing normative statements - if you're not doing nested authors MUST specify aria-level/setsize/pause/set on every tree item?
BGaraventa, how does aria-owns fit into this to reassociate when not nested?
Matt_King, you don't need aria-owns if it is within the tree
BGaraventa, so if you have a tree with a subtree, my understanding is the browser would calculate the set of grouping as its own level.
Matt_King, it does yes.
BGaraventa, where is the break down as far as the issue goes?
BGaraventa, I'm trying to understand what the problem is. Why is level not being computed properly?
Matt_King, the issue isnt level. Authors should be able to create a tree without any grouping, by specifying level/pause/set on every tree item. Then the grouping is optional. If you had aria-owns, in this case.. there wouldn't be any groups so you couldn't pull items from outside the tree.
Matt_King, if you want all the tree items at the end of the tree you could put the items on the tree element.
BGaraventa, different ways of doing it... I agree.
Matt_King, it wouldn't change the spec for aria-owns, I think.
Rahim, when role=group is provided in a tree; does anything else do this? Like nested accordions?
Matt_King, it happens in lists, if you're making an accordion you just do it with heading levels
BGaraventa, nested tabs? It should but I don't believe it does.
jamesn, there's something in one of the specs that details how this should work - but the prose needs work. I think there's an open issue.
Matt_King, browsers are not required to calculate level. There's no normative text.
jamesn, 1194 is the issue. Anyone want to take it on?
sarah, I can
Matt_King, sounds like we want to have someone to write a PR for this changing tree? Is this assigned?
jamesn, Sarah do you want to take this on too?
sarah, I'll take this on, what was the other?
Matt_King, we already have the browser language, it's just not worded normatively. It says browsers WILL not browsers MUST.
sarah, okay sure.
jamesn, looking at them together is useful. I never understood why we required groups in trees.
Matt_King, oh - Rahim, the other place this is important is menus. Menus do this too. That's probably where we see it the most. I don't think we do nesting in the APG - but I think we have the same problem there basically.
describe grouping (and naming of the group) for exclusive accordions <details name>
jamesn, oh we can't get through this in 3 minutes.
scotto, *laughs*
jamesn, let's wrap.