Meeting minutes
<aaronlev> My join instructions aren't working for the deep dive, and need to invite Mason Freed as well
discussing: https://
<aaronlev> https://
New Issue Triage
https://
jamesn: I don't think we can triage this without more understanding...
scotto: the person here is trying to create an apple date picker, where the picker popup shows up and you can swap, he is wondering why he can't
scotto: I think it's possible that he is talking about listbox, if you want to make all the items into buttons
jamesn: anyone agree?
scotto: I think he is trying to implement a different pattern into what a spin button is, so I can respond, unless anyone disagrees
<sarah_h> +1, that doesn't look like a spinbutton to me
jamesn: I agree
New PR Triage
Deep Dive planning
jamesn: we need another deepdive on popups
jamesn: when?
jamesn: or tpac?
matt_king: I think its a good tpac
jamesn: as long as we timebox the discussion, otherwise it could become a convo to long to be productive
matt_king: maybe if we had more deepdive time between now and tpac, then we can have the appropriate joint meetings with the appropriate working groups
aaronlev: I can't do it in the next two weeks
scotto: I think it's fine to wait a couple weeks
jamesn: we would be too late to get it into TPAC if we wait until sept for a second meeting
scotto: I won't be at tPAC
schedule for sept 1st!
matt_king: can we have a categorized list of the issues
jamesn: can we use github discussions?
<scotto> here is the list of issues that exists on open ui right now https://
aaronlev: I've never did that scott and I will figure out what to do
TPAC - please register. Hotels getting full
we are meeting the 15th and the 16th of sept
jamesn: we don't have a lot of people registered yet
matt_king: I'm coming
aaronlev: I'm coming I think
<chlane> I'm in the process too, won't be able to go phsycally
jamesn: conference hotel is already full, there is a hotel 5 min walk away that has a group price
jamesn: there is some availability for some dates if you aren't trying to stay the whole week
jamesn: agenda for joint group meetings
jamesn: APA is asking to meet with us
matt_king: can some of those joint meetings happen in other days
jamesn: I think we can't for APA because they are the same days as us
jamesn: or maybe we can do one on the 13 th with them, I'll ask
jamesn: they suggested the 15th, but I'd prefer to come to there meeting
matt_king: I'll be there all week
jamesn: valerie and I will be there all week
jamesn: any other questions? anyone confused?
"Whitespace characters" underspecified
jamesn: we talked about this last week, the proposal being made is to change the spec text to not mention white space and instead only override the existence of roledescription if it is the empty string
jamesn: I'm concerned about Matt's opinions
matt_king: roledescription=' ' would set the roledescription to space
aaronlev: we didn't implement even checking to see if it is the empty string yet
spectranaut: only webkit implemented the spec
scotto: jaws ignores empty roles, nvda says "no role" essentially
matt_king: if you put aria-label=" ", it is the same as not specifying, right?
aaronlev: I don't think so
aaronlev: I think aria-label="" makes the label empty
matt_king: but if aria-labelledby="" then...
aaronlev: there is no valid id so it is ignored
aaronlev: with aria-label, it is similar to alt, it is different to put alt="" then leaving it out
aaronlev: so we leave aria-label=""'
<jamesn> "Otherwise, if computing a name, and if the current node has an aria-label attribute whose value is not the empty string, nor, when trimmed of white space, is not the empty string:"
jamesn: accessible name script
jamesn: we do have the same problem with aria-label as aria-roledescription
matt_king: oh so I was right about that
matt_king: then I think we would want the same for aria-description....
jamesn: it is explicitly different, because you might want to overrride the browser tooltip, such as override to nothing
matt_king: I hate spagetti
jamesn: yes
jamesn: we have the same whitespace rules with aria-label and we DO need to fix it
jamesn: we would say it is an author conformance error, and authoring error in the spec, but the browser passes it along
matt_king: webkit implement the white space
jamesn: there list of white space list is not the full list, only common western white spaces
jamesn: and that is what the internationalization group is complaining about
matt_king: it seems to me that roledescription, if blank, should not be passed on
matt_king: no reason to do the same thing as role=presentation
aaronlev: when there is some weird self voice app that needs to do this to work properly. imo there is 500 million ways to break your code with aria, you would be shocked and concerned if you saw how complicated the browser implementations of aria, we don't want to add more complicate logic. we want to work fast, not crash, be understandable by developers. we can't pretend aria is something you can use when you don't know what you are
doing. I don't htink we should outsmart the author. I think the browsers should just be good at passing the information on
aaronlev: I don't think the browser should try to repair anything
matt_king: I think the idea of whittling down the error correction...?
jamesn: this is not in the error correction section
jamesn: which is mostly a "may", no one would objection
matt_king: if we added an author guidance and added to error correction section for UAs
jamesn: we need to add white space definition still if moving to the error correction section
jamesn: we need a CFC for this
matt_king: ok I agree considering what aaronlev said
aaronlev: I'm ok with an "authors must not"
scotto: I could do
scotto: take away the white space reference to convert text to authors must not do this
jamesn: and also reference an industry standard of whitespace
scotto: I'll link to wikipedia ;_
;D
Problematic User Agents MUST NOT statement needs to be qualified
jamesn: when we were removing 4 global states and properties, in 1.3, we added this
jamesn: a div with aria-label would be prohibited from exposing the aria-label of "foo" user agents are pushing back hard, like what aaron said above
matt_king: this is not error correction, this is just the same as html saying this content is not allowed in this content
<chlane> yeah like flow content
matt_king: the browser is not doing what the author told them... so it is kind of error correction... but the browser does have rules like that, it won't do anything you want it to do
matt_king: why can't the browsers do it?
jamesn: we break existing content if we prohibit this
jamesn: this is a general issue but there are only a few prohibited states
matt_king: I thought we wanted to break these things
aaronlev: we implemented it, and we reverted it, because we broke too many things
aaronlev: I wrote up a document with suggestions I was working on with james teh
aaronlev: if it is not duplicate text, it should be exposed to the user
aaronlev: none of the solutions were satisfying to james teh
aaronlev: one of the suggestions, for aria-label on a div or listitem (this is problematic but we don't disallow) -- expose as description or annotation?
aaronlev: we aren't reluctant to do anything, I just want to fix in a way that is satisfying for everyone
aaronlev: and doesn't break existing content
matt_king: I'm curious about what is getting broken, and I still don't understand why it's not ok to break
aaronlev: I did a test with list and list item combo.. scotto helped... jaws ignores name for list and listem, nvda... too many things
sarah_h: I have a question, would this also apply to generic elements that get focused, but what about nested buttons, buttons with a link
aaronlev: on focusable things, we ignore all prohibited rules, and expose the name, I think we have modified to only tabbable things
aaronlev: the button in button is a different issued but none of the browser trim content when children are presentational because it broke things
aaronlev: this is a good deep dive topic
jamesn: do we have consensus to make this an authoring error instead of a browser must?
<jamesn> https://
jamesn: we have talked about this before, and people have commented about use cases, consensus is to let validators handle it
scotto: last time we talked about this, was meant to be a author error, and only an author error, because of comments from even Bryan said about ramifications on accname
scotto: this should always have been an author must not...
jamesn: seems like for some reason we thought in the future we wanted the browsers to do this
scotto: I don't think we have everything in place to do this, maybe int he future we would want the browser to implement these rules
aaronlev: the current situation is totally broken and needs to be fixed
aaronlev: dominic wanted to NOT remove the name from the tree, but I disagree, whatever dominic thought we were not getting in screen readers
aaronlev: the author thinks they are creating annotation or a group of content with that name, so we should expose it in that way
scotto: to all those points, there is also a proposal that div tabindex=0 becomes a group!
scotto: at one point that was on the table
aaronlev: minimum role idea (?)
scotto: other elements not being div, the reality is all over the map on what this actually looks like when you get a screen reader involved, was talking to glen about jaws --- aria-label put on a link
scotto: jaws respects the children are presentational
scotto: and will not change no matter what the browser does
scotto: we allow namings on lots of things and this does create problems -- what to do when can get name from content and name from author????
matt_king: when something like link or button, when name from content, you put aria-label overrides the content
scotto: browsers are respecting that
scotto: screen readers think anything inside aria-label'd element should be ignored
scott: browsers are supplying the subtree
matt_king: <button aria-label="foo">bar</button>, bar is not in the acc tree
scotto: yes, but what if there is a heading in the button also
aaronlev: if there is a single text child, we do truncate it
aaronlev: but if there is more we pass it on?
scotto: the goal is for people to access content that they otherwise couldn't
matt_king: but this does not respect the spec, the author should count on subtrees being prunned
aaronlev: there can be multiple conflict rules. like fif there is a focusable inside of a button
matt_king: section 508 shouldn't be able to override the html sepc
aaronlev: we always expose the focus no matter what!
<chlane> I think buttons are only supposed to contain phrasing and flow content
aaronlev: I'm trying to set up 401k, or vaccine, the user comes first, prioritization of concerns, users need to get to the content
matt_king: but what if the author is counting on the rules to give the user a good experience
aaronlev: so that rule, were we expose contents in button, that doesn't cause a problem, but name prohibited DOES
aaronlev: can we do a deep dive?
jamesn: back to the issue, can we remove the statement that "breaks the web"
scotto: we can remove for not, put author must not, but we need find the instances that must no be followed
scotto: we aren't ready for UA prohibited
aaronlev: I think this is a great topic for tpac! I can come with 2 or 3 proposals
aria-disabled and descendant elements
jamesn: I'm confused
scotto: the point of this is in html you can set a fieldset to be disabled, but there are links, that should be accessible
scotto: if you want to disable a link don't use "aria-disabled"
scotto: the proposal is that link should nto be automatically disabled if children of nested disabled group
scotto: aaronlev said should we even do this all?
jamesn: don't allow aria-disabled on anything other than items
scotto: yeah no aria-disabled on grouping element
aaronlev: this isn't about usecases, just about mimicing fieldset
jamesn: what does it mean "if the rule doesn't go away"
aaronlev: I don't know what I meant
jamesn: I'm in favor of aria-disabled can only be applied to the interactive elements themselves
matt_king: I support
aaronlev: I'm fine with that
scotto: lets just remove from "group"
scotto: we can leave on radio group
scotto: we need to deprecate for "group"
jamesn: that what we should do
scotto: I'll update the PR that we resolved to deprecated from role group
scotto: and we can close the PR