<jamesn> meeting: ARIA WG
<jamesn> agendabot, find agenda
<agendabot> jamesn, OK. This may take a minute...
<agendabot> clear agenda
<scribe> scribe: sarah_higley
JN: aria-errormessage and aria-description -- Joanie, this is your spec. I believe aria-description shouldn't be there since that's not in 1.2 anyway. aria-errormessage probably should be
joanie: yup
JN: so we should put that in
1.2?
... I'm going to milestone this for 1.4 just so it doesn't
appear on 1.3 list since I don't think we have anything
specific for it (regarding the aria-deep-dive topic)
JC: you could move it to 1.4 and let Melanie do something with it
James: there is nothing in new triage
James: thinking about #762 next week, bringing VO actions to the web
JC: I don't think it's
necessarily limited to VoiceOver
... in general, an action that is exposed to the user through
AT
MK: yeah I don't think that was the intent, people were just talking about a possible model
JC: I just think messaging is important, so it doesn't seem like it's Apple imposing something
JN: James, do you want to update the issue to something more generic?
MK: some people will understand it better if you say "something like VO custom actions" in the title
JC: so I'm just calling it assistive technology actions, though it's not even limited to AT
MK: provide access to custom actions like how VO custom actions work
JN: ok, are we good to talk about that next week
JC: if you want me to present something, I'm not certain I'll have time
JN: I think we could have a
productive discussion without having a presentation
... it would be great to get some sort of specific action out
of the end of it, but I don't think these deep-dives will
always result in some sort of proposal
... I've also been bouncing ideas around about something like
hint text, there's lots of things people could want to do with
this area
JC: I"ll do some digging
regardless of whether I present something
... I want to make sure I'm adequately prepared for that call,
so yeah, I can do it
JN: so we're on for that for next thursday
JC: I'll update the title
JN: so these next three issues
and the ACT task force is asking what the status of these are,
they're blocked on them and we need to get them resolved
... we need to get people working on these
<carmacleod> https://github.com/w3c/aria/issues/1150
JN: so the first one of these is
1150, and this is unclear use of the term descendant
... I think at this stage going through and doing a PR on this
isn't necessarily the right way of going about it. I think we
need to go through and work out all the different uses of
descendant that we have
... doing an informal search of the spec, we have 4 different
uses. There's DOM descendant, descendant element (not sure if
the same as DOM descendant), and then we have other uses of
descendant, many of which are in activedescendant and keyboard
handling sections, and then we have random other things
... my proposal on this is that someone takes a look and tries
to categorize the usages of the word descendant into various
things and then we can potentially come up with a different
word for some of them and a definition, or a definition for
what descendant means in each of these ways
... e.g. "element descendant" and "DOM descendant", and define
each of those
... so anyone want to voluteer for this?
SH: I wouldn't mind doing some of that
MK: do they have to be fixed before CR?
JN: no, only if they (the ACT)
say they have to be
... so I'm not proposing fixing this in 1.2, I'm proposing as
soon in 1.3 as we can, and getting that in the working draft as
soon as we can
<carmacleod> Also https://github.com/w3c/aria/issues/1033 and https://github.com/w3c/aria/issues/1161
MK: so you're not planning of taking the results of this analysis and trying to get something changed in 1.2 after it's gone into CR
JN: we are going to try not to do
that, yes. We don't want to put anything new into 1.2, aside
from editorial changes, and this is not editorial
... I put a 1.3 blocking label on this to make it clear what we
are doing
... realistically if we recycle 1.2 and have to do some of the
process again, it's not going to be any quicker
... if you want to work with me, I'm happy to do it
SH: sounds good, I'll start with writing up what's currently in the spec and leaving recommendations off for now
<carmacleod> https://github.com/w3c/aria/issues/1033
JN: this one we have a PR, is
that correct?
... this is dependant on a different one
... #748, is that done?
... no
... so this is now dependent on something else, who wants to
think about this one?
... because these all need resolving
CM: is this all kind of rolled into what is a descendant
MK: no this is different, this is about what does required owned elements mean
JN: so does required own elements -- we really mean allowed owned elements
MK: no we dont actually, so that
is the question on the table. There are several scenarios that
are different. There's this question of things in a tablist
because we don't list button as a required owned element, is it
actually an allwed element, or is illegal to put a button in a
tablist
... so you can put a button in a tablist for a context menu,
and stuff like that
... so does required exclude other things? does it mean
allowed? how exclusionary is it, does it exclude generic? And
does it mean a child or a descendant?
... none of that is clear from the definition
CM: do we need another entry in the characteristics, so required means required, and we can add allowed?
MK: I don't know, because right
now in menu you can have group or menuitem, but you don't have
to have both, you can have one or the other
... and list, you have them marked as required but you can have
an empty list
SH: I think required is difficult because for most things you can have an empty container
JN: I think in most cases required means allowed, but maybe there are more things that should be added to that?
MK: in most cases allowed sounds exclusionary
JN: in most cases I've read required as exclusionary
SH: currently although I see a use case some times for other elements, it breaks certain AT behavior if it's not exclusionary
JN: so if that's not the intention, we should clarify
MK: yeah we would break the empty container thing if we changed it to required
JN: Matt, in your comment earlier:
<jamesn> At the same time, required owned elements has never been restrictive. In other words, it does not mean the same thing as "allowed" or "permitted" elements. ARIA does not currently have a concept of permitted descendants except where explicitly stated in prose via normative author must requirements.
JN: is that true that ARIA doesn't have a concept of perimtted descendants? because if that's not true maybe we should just drop required owned elements
MK: yeah I wish I had dropped some examples in here. I think this is a place where we should do some analysis
JN: actually so doesn't the required owned elements thing hit presentation as well?
SH: only if you interpret it as
children and not descendants
... I think I have a list of all the roles that have required
owned elements in a blog post
MK: that would be great to have
in a comment in the issue
... so we could interpret if it could be allowed without
breaking anything
... I know there are a lot of things that exist in the real
world where things would become illegal if it were changed to
allowed. That doesn't mean we can't do that, but what we might
want to do...
... is just be thoughtful about on some of these containers if
maybe... yeah, I guess we do need to think about if some
things... like if we have a menu with no menuitems, should we
require at least one menuitem or one group to be a menu
... but will it break AT if we allow an empty container?
SH: an empty menu should be allowed for authors, and AT can treat it as not a menu
MK: so if the browser were to handle that in the recovering from errors section, maybe we could leave that menu
<Zakim> jcraig, you wanted to say (after this topic closes) next week's deep dive preparation should include watching this 10-minute WWDC video on custom actions:
MK: i think it would be immensely
helpful to add that list of elements that have required owned
elements to the issue
... I think this is a topic that needs to be discussed with the
group
ah, sorry, just wanted to prevent zakim from complaining when I closed the topic
JN: I have no problem with containers being empty, a screen reader should just ignore it
IH: what should happen if the container gets focused
JN: generally the containers shouldn't get focuseed unless someone has messed up anyway
MK: yeah, they're all containery
JN: a listbox with nothing in it is focusable, but is allowed in HTML
MK: a lot of those are focusable
because they support activedescendant
... so is one of the questions here in some of these cases
would it be necessary to have both allowed an required? Do we
need both concepts? If we change required to allowed, do we
lose anything?
<jamesn> https://www.w3.org/TR/wai-aria-1.2/#mustContain
MK: are empty grids and tables something to allow? Because currently they're not permitted
JN: right now none of these things are allowed, which seems wrong
SH: I think there's a solid use case, e.g. when users can remove rows and they remove all rows
JN: or you can hide columns, and
hide all columns
... so here's it's saying that essentially it's invalid if you
do not have a listitem in a list
MK: which disagrees with html,
same with listbox
... so in html is an empty table tag permissable markup?
JN: I don't know
... I mean, it's not going to cause any problems, things are
just going to ignore it right?
MK: I don't know, but I think I would like to know that
JN: anyone want to investigate native html behavior for each of these things and work out what happens there?
MK: there's only four: definition/associationlist, table, list, listbox
IH: should I have a go at that?
JN: of course! and you can hassle Scott, that's even better
CM: so you're asking for two things? What does HTML say, and what does AT do?
JN: yeah, I think we should work out whether HTML allows an empty table or row, then we should work out what actually happens in accessibility APIs
MK: I said there were only four, but now that you bring that up, can you have an empty row, or table body?
JN: yeah we should, but we should probably start with investigating just the top-level things. We don't need a complete analysis
JD: I agree in spirit with "also see what ATs do" but ATs are often working around browser and author weirdness, so as an interim step we should look at what is exposed to us using accessibility inspectors, independent of what the screen reader is actually saying
JN: yeah, I agree Joanie
... Isabel, if you need help please ping me
<carmacleod> https://github.com/w3c/aria/issues/1161
JC: just a quick note for the
group, ahead of next week's deep dive, there's at least one
10min video that would be helpful for everyone participating in
next week's deep dive to watch
... this is a video from last year, and there's a second from
this year as well on custom actions. I'll add the link
JN: ok, 1161, inconsistent use of
owned by
... Scott had a pull request, 1213, which still has a bunch of
comments in it
... I think we need someone to take over this pull request
<jamesn> https://github.com/w3c/aria/pull/1213
<carmacleod> PR: https://github.com/w3c/aria/pull/1213
CM: all right, I'll take over
MK: I'm just looking at this quickly, but is the generic role considered presentational?
JN: a generic role is not presentational, I do not believe
MK: I just kind of wonder in this
PR, I'm looking at Scott's summary and I'm wondering if it
should be presentational or generic (instead of just
presentational)
... if we're doing presentational we should do generic as
well
... it seems to me it should be that presentational or generic
things should just be empty containers, or empty except for the
context
JN: I know you're essentially trying to avoid people having to do <div role="none"> which you have to in many places
MK: I want to make sure it's
allowed to have an empty div even with role="none" because
there was some interpretation of this that it needed to be a
direct descendant, and I think it needs to be a direct
descendant in the a11y tree and any divs should be
ignored
... I'm thinking back to Alice and her efforts to standardize
the a11y tree and the differences between Chrome and Firefox or
Chrome and Webkit
JD: just as a clarification, about a year ago there was a bunch of a11y tree pruning, so I no longer complain about that
JC: there's still a ton of differences between the trees, and the bunch of divs Matt mentioned can still cause problems, and it's unclear whether that should be resolved in browser engines or ATs, but we should clarify the a11y tree regardless
JN: This PR is attempting to define which elements are allowed as intermediate containers between things that have required owned elements, is that correct:
JC: one of the challenges is even
if you have a generic one like a div, if it has style props
associated with it like layering and bounds it has to be
exposed to the a11y tree in order to compute the position for
things like VO cursor, so we can't just take it out without
breaking everything
... so if a user includes them but doesn't add something like
role="none" or role="presentation" a lot is left up to the
browser engine
JN: so maybe authors do need to add role="none" but we should at least clarify that so authors know that
JC: that puts a lot of onus on the author, but that would at least make it clear
JN: if tools can check it, that at least makes it clear that they have made an error
MK: I think ARIA doesn't distinguish between div, span, and address in HTML but it feels really onerous to require role="none" on a div in between a gridcell and a row
JN: I agree, and I've hit these errors so many times. Realistically at the moment it's the only solution we have today without getting browser engines to change
MK: I don't know, it seems like
this issue is calling out whether or not we have to do that,
and whether or not we put that in the spec
... I don't know if I'd object if it really is truly necessary,
but it's hard for me to understand why it's truly necessary
JC: James, your comment about not
getting browser engines to change, we should certainly strive
to get browsers to change when necessary. In this case, I think
it's not entirely clear what the browser should do if it were
to change.
... I think we'd have to get AT developer buy-in on those as
well, because sometimes when we've changed some of those things
in the past it's broken something down the line
... according to priority of constituency it's something we
should change, authors over implementors
JN: But if we specify that style attributes affect things, we crawl into this place where someone adds another stylesheet to your page and suddenly everything's broken
JC: I think we need to just
specify that it's just always required, or we need to add some
specific advice for implementors, and I think I lean towards
implementors more
... because we're always going to have authors who put
something like a button between cells
JN: if we can, that seems
awesome, but compared to everything else we have to solve, it
seems like we have a hard time getting implementors to agree
on
... Carolyn, thanks for volunteering to give this a go
... we'll talk next week about context menu thingys, and then
no call the week after for thanksgiving
rrsagent make minutes
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/htem/them/ Default Present: StefanS, Joanmarie_Diggs, jamesn, sarah_higley, carmacleod, Jemma Present: StefanS Joanmarie_Diggs jamesn sarah_higley carmacleod Jemma CurtBellew Regrets: Harris Peter Jon Found Scribe: sarah_higley Inferring ScribeNick: sarah_higley Agenda: https://lists.w3.org/Archives/Public/public-aria/2020Nov/0014.html WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]