<jamesn> agendabot, find agenda
<agendabot> jamesn, OK. This may take a minute...
<agendabot> clear agenda
<jamesn> 🥮
<scribe> scribe: jcraig
#1330 https://github.com/w3c/aria/issues/1330
jamesn: okay to close?
carmacleod: close and ask for forgiveness
https://github.com/w3c/aria/issues/1329
StefanS: [inaudible to scribe due to low mic?]
jamesn: milestone 1.3, Scott already linked to #1325
Scott_O: agreed. I think we may not need to keep #1329 open... Same issue as #1325
StefanS: I don't agree
Scott_O: I think the solution (new role) would solve both
StefanS: we have specialized roles in ARIA already... what is missing is generalized [scribe help]
I forgot to add Chart Sonfication API
jamesn: No Deep dive topic next week unless we hear otherwise
<carmacleod> https://github.com/w3c/aria/issues/1052
jamesn: plan of action from deep dive call: Sarah and Matt are going to brainstorm this offline
sarah_higley: Aaron, how difficult would it be to change the aria mapping for selected and checked?
on a single select, if focus is not specified, [sarah clarifies below]
Sarah/Matt: when you want it to map to a non-selectable tree item
Aaron: Would need a browser change to make that happen
<sarah_higley> on a single select, if selected is not specified, then the focused item is selected and all others are not selected. On a multiselect, all items default to not selected. How hard would it be to change that default mapping for a browser?
might need a SR change too... If update to JAWS needed, sometimes it's not worth the effort.
Can you navigate to them?
sarah_higley: would like to replace selected with checked
Matt_King: if author is using checked and is not using selected (checked replaces), we need to make sure selected is not "communicated" [sic] (exposed to API?)
Aaron: could we use aria-selected=undefined
sarah_higley: we could test it
carmacleod: sounds difficult to explain to authors
Matt_King: not opposed
Aaron: or aria-readonly, or another attribute that means explicitly this is not selected
even experimental aria-floof="" so I could test how it works with SRs
carmacleod: should aria-floof be on the container?
Matt_King: Sarah and I will play with this idea
sarah_higley: strongest use case is mixed state checking on trees
if you use aria checked and selected, you get both states at once..
Aaron: do we have consensus?
Matt_King: we want to leave users
the magic bullet, knowing that some may use it to shoot
themselves in the foot
... if we had property on the tree that said, in this tree
checked is equivalent to selected, would that make you less
nervous?
Aaron: maybe if we had more properties on the listbox
Matt_King: could ask authors to be cognizant, but allow selected or checked on the tree
Aaron: I think adding checked won't break anything
Matt_King: and make sure selected is not mapped if checked is exposed
sarah_higley: and ask SRs to
avoid speaking/brailling "not selected"
... API support for checked is missing on UIA and AX API
entirely, and aria-selected is still mapped when not defined
and checked is present (not sure if that's exactly what was
missed)
Aaron: can prototype this in Canary
Matt_King: Sarah and I will work with Aaron on this
jamesn: wait for previously mentioned discussion
<sarah_higley> sorry, I missed what I was supposed to minute 😅
<sarah_higley> API support for checked is missing on UIA and AX API entirely, and aria-selected is still mapped when not defined and checked is present (not sure if that's exactly what was missed)
<aaronlev> https://github.com/w3c/dpub-aria/pull/28
<sarah_higley> aria-checked is mapped by Firefox and Chrome to IA2, and works on Android (did not inspect the API directly)
aaronlev: should have just header and footer and not number
carmacleod: seems okay to me
jcraig: role abbreviations okay in DPUB. that convention is to match existing abbreviations in EPUB. full expansion is convention for core roles
<carmacleod> DPUB-ARIA PR to review: https://github.com/w3c/dpub-aria/pull/28
Matt_King: header, footer, pullquote were the ones I recall.
Aaron: yes, already a
doc-pullquote in DPUB..
... Tzviya and Matt Garrish emailed about this
jamesn: they want to make this change to fix invalid documents
jamesn: Wilco pinged on this topic again
carmacleod: wilco either provided PR or working. I responded that the wording didn't solve the problem. Ongoing discussion.
See: https://github.com/w3c/aria/issues/1033#issuecomment-683311902
So, keeping in mind the definition of Owned Element:
An 'owned element' is any DOM descendant of the element, any element specified as a child via aria-owns, or any DOM descendant of the owned child.
how about the following:
Required Owned Elements
The role required for owned elements in order to complete the semantics of this role.
For example, an element with the role list will own elements with the role listitem.
All owned elements SHOULD have a role from the list of required owned elements.
matt: re last sentence. that can't be
carmacleod: wilco did not like the last sentence either
wilco proposed splitting owned into two categories
See https://github.com/w3c/aria/issues/1033#issuecomment-688760865
Matt_King: spec is ambiguous about, for example, can a tablets "own" a button.
Melanie: I am assigned to help with this one, but I have to leave early. Will update the issue.
carmacleod: link yours to #1033?
Matt_King: maybe 3 issues then
jamesn: I will link these minutes to the issue
Matt_King: there should be language that explicitly does not restrict what type of element is owned by an owning element [?]
Scott_O: agree with Matt...Required owned elements are required, but should not exclude other elements besides the required owned elements
Matt_King: listbox explicitly states it must only contain options or groups of options
characteristics tables do not encompass all requirements for the table...
carmacleod: listbox role in spec does not have this in normative language
same for list
Scott_O: HTML indicates explicitly allowed children... This seemed like it was missing in ARIA
jcraig: tried to allow flexibility by never disallowing how web authors nest their tag soup, if they get it close enough that the browsers can expose the right thing to the API, that should be enough. If the spec is too explicit about the structure of composite widgets, most web authors won't be able to match it due to other constraints such as stylistic or other functionality the ARIA spec did not anticipate.
sarah_higley: some problems, for example, when you add buttons in a list
you can have empty lists
jcraig: that aren't busy?
sarah_higley: ex: empty todo list
so the required owned elements aren't actually required
jamesn: we need to wrap the call... thanks everyone. adjourned.
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/flood/floof/ Succeeded: s/[sarah replace]/[sarah clarifies below]/ Succeeded: s/[scribe help re API support]/API support for checked is missing on UIA and AX API entirely, and aria-selected is still mapped when not defined and checked is present (not sure if that's exactly what was missed)/ Succeeded: s/okey/okay/ Succeeded: s/Tzvyia/Tzviya/ Succeeded: s/[scribe tbd]/[inaudible to scribe due to low mic?]/ Succeeded: s/as editor, tried to never disallow flexibility/tried to allow flexibility by never disallowing how web authors nest their tag soup, if they get it close enough that the browsers can expose the right thing to the API, that should be enough. If the spec is too explicit about the structure of composite widgets, most web authors won't be able to match it due to other constraints such as stylistic or other functionality the ARIA spec did not anticipate./ Present: pkra James_Craig Joanmarie_Diggs jamesn StefanS Scott_O sarah_higley carmacleod MarkMccarthy harris Matt_King Found Scribe: jcraig Inferring ScribeNick: jcraig Agenda: https://lists.w3.org/Archives/Public/public-aria/2020Sep/0033.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]