Meeting minutes
big fan of Sarah's tooltip rant
New Issue Triage
1717 editorial
1716
scott looking at it
assinging to scott
aam 393
scott looking rewriting that
New PR Triage
zakim. close this item
Deep Dive planning
dialogs rescheduled to 4/7
week after next, follow up on secondary actions if needed
other thing, have an Open UI catchup
scotto: agrees
jamesn: should we do that on 4/14?
sarah_higley can attend
ARIA APG migration plan - latest preview
website rather than a note
won't be versioned
things will break
target is GAAD for the site to go live 5/19?
GAAD is 5/19
people can see latest preview
jamesn: some things in flux
not complete, major comments speak up
ask questions using mailing list
JaEun is available for questions
still reviewing content you can also file an issue in their github
Meeting Time
jamesn: one attendee can't make current time due it being 3am for him
jamesn: what is the earliest or latest time in the day
jamesn: if we want to have a global meeting ... trying to think about to make it work for all
jamesn: could change the meeting day
3am or 4am not suitable
jamesn: will put in a poll
jamesn: or different times/weeks
people may miss
[Update paragraph in option to remove DOM focus requirement #1682](https://github.com/w3c/aria/issues/1662)
<MarkMcCarthy> https://
<jamesn> https://
1682 is the correct one
sarah_higley was looking at it
sarah_higley: talked about this 28 days ago
<Jem> https://
sarah_higley: 1682 needs discussion
[Support aria-description](https://github.com/w3c/accname/pull/69)
bryan doesn't know current status, aaron had family emergency
[Secondary actions on items in composite widget roles](https://github.com/w3c/aria/issues/1440)
<jamesn> https://
sarah_higley: wrote a proposal for aria-actions
takes an ID list of secondary actions
for an element
would effect naming algo
children would be normally be skipped
aria-controls should refer back
should be allowed on other roles
jamesC brought that up, and video play/pause/mute
range of roles this would be allowed on?
range of roles allowed to be secondary actions?
should the allow roles that can be secondary be limited
?
StefanS: adding icons for delete, select, tons of more actions if you press shift f10 for context menu
you can always have more actions than depicted
context menus and keyboard shortcuts should also be considered
list items, options that contains a click handler
aria-actions would be valuable for these kind of things
sarah_higley: context menus are a good point
attribute is intended for ID that exist in the DOM only
aria-actions would not be necessary if there is a context menu
this is more for things in the DOM
the ref IDs must exist in the DOM
the actual mechanism to expose it would be to announce "three actions available"
if I
this attribute is not scoped to that
stuff built into browser like key shortcuts, I think it would be great
when browsers create <select> menu, more flexible content in native elemennt, browser could add feature
scotto: would agree, being explicit is less prone to guesswork
<cyns> +1 to scotto
<Zakim> cyns, you wanted to ask about default keyboard behavior, also wondering if it would be a good idea for a browser to expose these actions as a context menu
cyns: wondering what default kb behavior be?
tabs stops, if running a screeen reader different behavior?
might be useful for a browser to collect things?
sarah_higley: would love if browsers collect ref ids and put them in a context menu
sarah_higley: what roles are allowed? would be really cool
virtual/cursor suggested shoulds/musts
ref controls must exist in the dom
there must be a keyboard mechanism to navigate between primary/secondary
linear list left/right arrows
context dependent linear vs tree
the aria attribute should specify kb behaviors
cyns: no change to default behavior
sarah_higley: say mechanism exists
select menu in open UI would be the best place to talk about it
siri_: likes approach, social media like buttons can be informed to screen reader users
how to tie up with message, it will help
if you reference by ID, having so many buttons, if we want to provide an explicit label for all is it repetetive, too much?
sarah_higley: part of the mechanism, is to change acc name step 2 f3 processing children
secondary action children would not contribute to the accname
don't know how screen reader will expose
something like "three actions available"
a UX choice for screen reader vendors
scotto: would solve details summary list
scotto: taking a page from voiceover, navigate to heading with nested element and hearing "heading with 3 items"
<MarkMcCarthy> sarah_higley: +1
<Zakim> jamesn, you wanted to ask if we are limiting secondary action roles?
scotto: VO does that , made plea to jaws to do similar
bryan on queue
jamesn: are we limiting the things that can be secondary actions?
jamesn: only allow certain roles to be secondary actions
sarah_higley: combobobox with a combobox secondary actions
jamesn: limit to widgets not composites
scotto: search field
sarah_higley: for a text field, people try to put enter your fav item then there is "other"
jamesn: not stop things like that
want to limit a bit
jamesn: can't imagine a grid a a secondary actions
myasonik: tertiary actions?
jamesn: takes that pointed
bryan, aria-actions on focusable element and ref the id of the action element?
sarah_higley: yes
bryan, what interestets him, the exclusion from recursion in naming, common issue
if you have col header that references a aria grid
menu buttons in columnn header
crap is put in acc name
would be awesome to find a way to exclude things from algo
sarah_higley: was hoping this scenario was covered
<Zakim> jcraig, you wanted to suggest limiting the primitive may not be necessary and to mention I'm not even sure the container or the referenced action elements need to limited to focusables
jcraig: see a trend to develop an API, want to encourage those open and primitive
to be more flexible
limitations lead to workarounds
if antipattern arises
add futere limitations
times when something causes nothing on the doc to be accessible
limited to generics
checkboxes. textfields could be actions
clicking on 'other' button
dialog to popup is reasonable
video container
buttons or click on entire container
not limited to specific roles
or just focusable
limit to AT focusable
close action on dialog button not a11y
don't stick to the box we have now
<MarkMcCarthy> +1 to jcraig, that seems a reasonable explantion
keep it primitive (not overly limited) and ONLY add limitations when antipatterns arise
scotto: secondary actions, would remain siblings, could see aria-actions pointing to any interactive element
scotto: JAWS still treats these things that's presentational
mish mash of error correction in browsers
some nested interactives not allowed
like textbox inside an option
scotto: good for column headers but would not resolve bigger issues
make abbr attribute on col headers
<Zakim> myasonik, you wanted to ask if we're ok encouraging child actions
myasonik:
child action not encouraged in spec?
can we limit this to video players and open UI select?
do we want to encourage authors to do it
<jcraig> Actions is available on iOS with no limits and app authors use it for a lot of great reasons we never anticipated
sarah_higley: make aria-actions an exception to children presentational
sarah_higley: the idea of allowed roles as id refs for aria-actions
widget roles make sense to me
does not make sense to referenc a paragraph with aria-actions
limiting will help when encouraging browsers to do something like provide shortcut or add to context menu
but over limiting is not great
<MarkMcCarthy> Seems like a great idea!
+ MarkMcCarthy
james c this does not out the user
<scotto> great job sarah
<MarkMcCarthy> 🎉