Meeting minutes
New Issue Triage
jamesn: under discussion, do we need to agenda this scott?
leave it for now, monitor it
jamesn: grouping for accordions... scott can you do the same? agenda it if necessary?
scott: I think we can throw it back, it should start in html
scott: not in html-aam
jamesn: sounds editorial
jamesn: I'm guess we need someone to take ownership....
Rahim: I'm happy to do that change
Rahim: does the group agree
Rahim: in css 3, generated content, they use "alternative text" instead of "text alternative"
jcraig: maybe this should be defined somewhere... we should define a spec maybe in WCAG, then reference it?
jamesn: this instance should be changed though
jamesn: sounds kind of editorial....
Rahim: I raised it, happy to do this one
jamesn: does this need agenda-ing?
jamesn: I'm not sure if will be controversial, but people should read and think before talking about
scotto: this is related to what we talked about recently.... we said in previous meeting that title should not be part of the accname calculate for generics...
jcraig: I think we should talk about that -- this would be author provided text that would keep web engines from exposing it
jcraig: even though a sited user could hover over and see it
scotto: it's not my intentional to get rid of it, it should go to description algorithm
jcraig: since the name algorithm is normative.... if we explicitly exclude them
jamesn: it is agenda'd
mcking: last week I meant to raise an issue for prohibiting describeby on generics
New PR Triage
james: who knows idl and wants to review?
jcraig: I will take it
jamesn: non normative
jcraig: you can add me as a reviewer
jamesn: anyone want to review?
(got reviewers)
bryan: I'll review
scotto: I'll review
WPT Open PRs
jcraig: I think only mel's is stalled....
#34
<jcraig> web-platform-tests/
jcraig: the rest are in progress
Take ownership of ARIA in HTML from webapps
stefans: isn't this the holy bible of the validators?
stefans: the only thing that defines the relationship between aria and html, and I think it only has advantages to own it
jamesn: please speak up if you have a problem with this
jamesn: but I will do a CFC to make it recorded
<pkra> +1
<stefans> +1
popovertargetaction=show/hide when popover is already shown or hidden
<pkra> because scotto is the best (tm)
scotto: ok.... I'm worried about the future of this with other stuff going on in html. the crux of the issue is that a popover, in response to a button, can open or close it, or, it can just open it, or, it can just close the button. most use cases will probably be toggle, some will be only open, and in some, it might be closed
scotto: when you could expand and collapes a table, two different buttons
scotto: a button is set to close, but the popover is already closed, it doesn't do anything. it announces it is in the collapsed state... there is nothing to indicate why nothing is happened
scotto: discussions about aria-expanded being added to a button that only closes the item
scotto: should we programatically disable the buttons when they don't do anything? am I over thinking it?
Matt_King: I don't think you are overthinking it I have a big concern about people using expanded and collapsed and pressed and not pressed on elements that don't actually toggle. I run into this a fair amount, as a user, this is a really hard to figure out... somethings you can deduce but you have to do a lot of looking around. depending on context this could be hard
Matt_King: I would prefer there was not expanded and collapse on it at all, if is labelled opened and disabled, then its clear it is open
Matt_King: I would find it confusing if we also had expand/collapse
sarah_h: I would learn against making a button prorgammatically disabled.. having one html attribute that is more of a utlity attribute, it does one thing (shows or hides) having it do extra magic of disabling once the button is open.... I think it would be unclear to authors. there are times when we run logic -- look for buttons that are disabled -- if you need to manage focusablity. would we keep it focusable but disabled?
sarah_h: if it's disabled, we would assumed it is not focuasable
sarah_h: also... the pattern of having a button that toggles a popup, I've never seen a pattern where the button becomes disabled
<scotto> here's an example of the current behavior for anyone unfamiliar - https://
sarah_h: I'm not sure it should be disabled
jcraig: I agree with sarah
jcraig: if the magic were to happen, it should be standard html or openui function
jcraig: if they agree it should happen, it is discoverable by authors
jcraig: I don't believe this magic should happen only on the accessibility side -- at least some AT, voice over used to not even try to click a button if it says it is disabled
jcraig: anyone could add another click handler on that button that runs another function
jcraig: this button isn't disabled, it is just not doing anything
Matt_King: I'm not sure what we are talking about now -- what I am talking about is what authors should or shouldn't do -- if we are talking about browsers doing some magic, my bigger question is to what extend....
Matt_King: I think the bigger question is the way people are coding things, by default does it encouraging/supporting situations where we create things that are really difficult for users. you can already make a button does nothing -- you should somehow indicate that. I think you should use aria-disabled instead of disabled because often it is useful for these things to be focusable
Matt_King: dialogs have separate close and open, one is inside and one is outside
Matt_King: I've never seen two buttons by each other where one only opens and one only closes
Matt_King: it is up to the author to say if it does nothing
scotto: again I just posed the question because I don't have a strong opinion, but I have heard from some of my coworkers, that there was an announcement that it doesn't do anything
Matt_King: is there anything stopping the author from putting aria-disabled truee?
scotto: the whole point is to not have to do extra stuff, like javascript or aira
scotto: maybe we just shouldn't have aria-expanded, it's a button that doesn't do anything
Matt_King: if the browser absolutely knows that it doesn't do anything, and, if, the whole point of the pattern is to avoid having to use extra aria and javscript, and we want to provide an accessible experience, then it is imperative that we provide some indication to the user that the button does nothing
sarah_h: I don't think the browser does know that the browser does nothing, for example, a popover that shows on hover, but if you click the button it pins and puts focus on it. it would be open, but you could click it, and the popover is pinned
sarah_h: I see a few possibilities, but if you can get to the button if the thing is opened or closed, and pointer users could still get to it, its already weird for a pointer using person to get to a button that does nothing
sarah_h: so it is the web authors decision to leave the button clickable or not
sarah_h: we shouldn't overwrite it
<Zakim> jcraig, you wanted to ask won't most authors hide these from view when they aren't usable? seems like Matt's concern may be alleviated by the fact that most authors probably wouldn't expose that confusing UI
scotto: I see both sides of this, just tell me what to do
jcraig: maybe I am misunderstand the pattern, but most authors will put the close button on the popover -- or will this show up at all times anyway?
jcraig: what is stopping them from using this common pattern. this is already an edge case
<Matt_King> I am wondering if there are changinges to popover that could address to adress the situations that Sarah raised, which are really good use case examples
jamesn: it would be good to have some examples of where this is uses
scotto: sounds like maybe there are changes that should be made to the non-aria spec or author guidance
Clarify how aria-* attributes are expected to trickle down to nested elements
jamesn: this was filed based on the grid and readonly on a row, would that trickle down to a gridcell, would it trickle down to elements within the cell? or if you put on a group, does it trickle down to the things in group
Matt_King: I seem to remember writing a whole bunch about this in the spec of 1.2.... is it not clear in the spec???
Matt_King: I thought we said we are limiting trickle down... I need to read the issue
scotto: I added another issue, we were discussing allowing diabled on group, unlike fieldset on html, the fieldset only trickles down to the form elements
scotto: but on a group, it trickles down to anything focusable
jamesn: (reads the spec)
jamesn: (for aria-disabled)
Matt_King: is there not another issue related to disabled on group?
Matt_King: there are a lot of things that could be in a group, and could be focusable
<Zakim> jcraig, you wanted to say this sounds like a magic bullet to load in your footgun
<sarah_h> a magic bullet for my footgun sounds like something I would find in a DnD campaign
jcraig: it sounds like a convenience method ... I'd be wary that authors expect it to work. I could could around to things that aren't disabled...
Matt_King: how many apps are already using aria-disabled in groups?
jamesn: the conclusion is that we shouldn't expand the use, you should put aria-disabled on anything you specifically want disabled
<Zakim> jcraig, you wanted to discuss a proposal
jcraig: maybe this is naive, but there are things like aria-hidden that obviously apply to things below them, where as aria-disabled shouldn't cascade down, do we want a new characteristic in the characteristic table?
jamesn: aria-hidden is kind of like the exception -- we don't want to create something for an exception, do we?
Matt_King: I'd have to look at all the states and properties
Matt_King: I'm wondering if removing aria-disable from somethings... we might consider removing it from these container elements
jamesn: we could consider it yes
jamesn: we have concluded we do not want to expand usage
<CurtBellew> +1
<Rahim> Seems like we would encounter similar challenges with role="presentation"
jamesn: who should write a response on the issue 1972 about grid rows
scotto: I'll doit