Meeting minutes
<jamesn> - this week (Apr 29) Accessible name prohibited issues
<jamesn> - next week (May 6) - aria-roledescription (stes-acc)
<jamesn> - 2 weeks (May 13) - Data Visualization part 2
[New Issue Triage](https://bit.ly/2QDnJKM)
Issue: https://
jamesn: three new issues, two of which we discussed in the last hour, we need to get this resolved quickly
jamesn: resolution is that the issue (1476) is assigned to scott and myself
jamesn: issue 1474 also assigned to jamesn
[New PR Triage](https://bit.ly/32WPhxg)
jamesn: 1475 we need two more reviewers, who would like to review.
jcraig: you can assign me as a reviewer
jamesn: oh cool we already have three reviewers, also it's good to have one reviewer that wasn't in the deep dive convo
jamesn: the other one is editorial so I'll resolve, we don't need to discuss
Upcoming Deep Dives
jamesn: next week we'll discuss aria role description next week, data viz part 2 the week after
jamesn: may 20th we'll discuss accessible name prohibited, focusing on what to do with focusable divs and what their role mapping should be
siri: all these sound super interesting but they all conflict, can we record?
jamesn: we do release minutes from these; recordings aren't typically available publicly unless everyone present agrees to it
cyns: are there calendar entries yet?
jamesn: no not yet we just decided on these
(discussion about subscribing capabilities for calendar use)
<cyns> Calendar subscription: https://
jcraig: deep dives are harder for me lately, so please ping me if you need me there so I can block my calendar
[Roles with required accessible names](https://github.com/w3c/aria/issues/1466)
scott: "this" is a good way to describe this issue
scott: accessible name required row- sometimes it's true, false or not there at all. it should be consistent.
jamesn: what do people think?
msumner: I think it should be Accessible Name: Required, Not Required, or Prohibited.
bryang: that sounds correct
jamesn: okay cool but also this is more scripting work
<jcraig> Approved PR #1475 https://
scott: so do I need to change it from "Accessible Name Required" ?
jamesn: I am not sure we should do this because there are things that reference this and all those references would have to be updated
carmacleod_: it does get a bit more complicated
scott: so let's then just do Accessible Name Required: true, and not put rows in for false or prohibited
(no objections, general agreement)
scott: next up we have "landmark SHOULD" - I think we want to call out some author guidance around landmark roles when there are multiple of the same landmark
jamesn: do we have an issue that says we should have links to practices?
carolyn: no but it's a good idea! there are a lot of links that could be added
scott will separate out the "landmark Should" section to a separate issue so it can be worked on separately
scott: right now if role="group" is named, it wouldn't be exposed, so it's missing name required.
*is not named
jamesn: can't you have an unnamed fieldset? so why wouldn't we allow an unnamed group?
scott: yes but that makes fieldset kinda useless right?
bryan: group is used for other things where you wouldn't want group to be named, like if it contained a tree
jamesn: sounds like we need an authoring note that sometimes it needs a name, and give usage examples
discussed APG guidance
scott: ok so for this one it's a no
scott: next up is tab and I don't think that makes sense w/o a name
carolyn: good point
jamesn: it says "name required only if content is insufficient"
jamesn: anyone disagree that tab should have accessible name required? (no objections)
scott: next up is separator: it says "if focusable" and I think we should give it more guidance
jamesn: I think we do stuff differently for things "if focusable" so I think it makes sense for accessible name to be required
siri: I always saw separator being used in APG in examples, but where is it focusable?
scott: a focusable separator might be one like between two window panes where you could adjust the width of the panes
bryan: do they even do this on the web? I haven't seen it.
sarah: is there some documentation anywhere about this?
jamesn: there were plans for a proposal for authoring practices about this, it just hasn't been a high priority
jamesn: typically it's the non-canvas, window-splitters where we tend to use this sort of pattern
jcraig: Mac uses no label by default, but a role description of "splitter" and a [vertical | horizontal] property. A VoiceOver user can interact with it, then control it like a slider: increment or decrement.
bryan: I've never seen one that was usable and intuitive on the web
jcraig: yes it's been difficult to implement but we have increment and decrement now so it's possible
scott: ok so it shouldn't have name required
(jokes re: tooltip)
jamesn: tooltip supports name from content
sarah: clarifies that there's no issue if a tooltip doesn't have content (and it just exists as empty)
bryan: (if you put aria-label on a heading, it obscures the content of the heading- there are situations similar with tooltip where it can obscure content)
<carmacleod_> +1 for removing name required from tooltip
jamesn: decision: not require a name for roles of tooltip, label and legend.
no objection
scott: some other questions- "tree and treegrid require a name, but other similar roles (of varying similarities mind you) menu, menubar, toolbar, tablist, and navigation do not. should tree/treegrid continue to require a name, or should some of these other roles require a name too?"
scott: also "do alertdialog, dialog, table, grid, tabpanel need a quantifier to their required name status?"
jamesn: what do we think we should do about this?
carolyn: again, we should be pointing to APG. it would be nice to point to that naming guidance table
jamesn & scott: discussion about how the article element gets its name
jamesn: I think we need a longer conversation on the "labeling things"
scott: I got what I need from this, I'll get it done
[Suggested simplification](https://github.com/w3c/accname/issues/96)
<MarkMcCarthy> msumner: i wanted to rearrange and update things, and hopefully move forward with rewording things in another PR, all taking into account James Teh's comments
<MarkMcCarthy> msumner: no wording changed, only rearranged things so far
bryan: I'm having a hard time reading the code changes can you email me
msumner: sure will do
jamesn: there is a reference there that needs to be changed
jamesn: I'll give it a review as well, I agree that we should keep it to a small change and other things should be subsequent issues
jamesn: ok we're at the hour!