Meeting minutes
<jamesn> what do OpenUI anticipate needing our assistance / feedback on
<jamesn> communication mechanisms
<jamesn> How can each group more effectively help the other?
<jamesn> Gaps in ARIA which need filling?
<jamesn> Things ARIA is working on that need prototypes?
<JonathanNeal> !present
scribe chlane
What has openUI been up to since we last met
jcraig: last met 9 months ago
3 minute catchup from open ui?
what you've been working on
bkardell_: Scott can do it?
scotto: been in both groups
largely seen work with popup tab component, select menu as a replacement for ?
github issuess. less insight since a lot precedes my joining
research docs are screen shots
from patterns
more recently poking at reviews
bkardell_: decent summarry
those were the focus
focus group has moved to open ui
microsofts proposal
early, css toggles
chrisdholt: hope is to not be to additive
add to existing patterns
travis has current state
bkardell_: recommends watching recording
jamesn: move on?
hdv: tabs, panels accordions, what is a good ux for AT
what is in the wild
whats devs want and what works for AT
bkardell_: open UI is a long process
twists turns
popups great example
scotto helped
matt, not familiar with process
jamesn: come into that later in agenda
siri_: browsers not acting consistently?
jamesn: not open UI related
jamesn: zakim, next agendum
<bkardell_> maybe it is helpful to say that openui is a special part of wicg - it is for pre-standards incubation, a lot of things in there might never make it all the way to standards but can at least help libraries align and inform, etc
What is the overall process for group collaboration?
jamesn: next to skip over
right now, someone works on something come back with prototypes not plugged in when something is missing from a11y point of view
we need implmentation in real components
open ui has been workig around issues
come to us when there is a gap
we go to you when we need a feature
how to make that happen?
JonathanNeal:
jamesn: JonathanNeal: the ideas that come through, articulate a need, phase concepts, prototyping
speculative concepts, explainers
at this point its called a prototype
before ideation, come to ARIA
before explainer or prototype
chrisdholt: agree
to validate expectations
don't match reality
opinions internally about our gaps
more holistic solution, larger mindshare
<JonathanNeal> I would like to note that I am not sick of hearing Scott O’Hara talk.
matt , like shift left
investigations, explainers is supposed to involve user research
before going forward to something implemented in all browsers
not certain what most usable/accessible approach might be
can anyone answer that?
what is the investigation phase?
hdv: look at what APG does
not user tested
as far as we know
not just based on assumptions
we can work together on that
<JonathanNeal> I would add that the investigation phase involves a significant effort to collect Prior Art.
matt partnering would be great
apg tries to dumnb things down
avoid complex patterns
a lot of things that people want to do
that we have not addressed
in some cases due to lack of agreement
in some case we have to work around a11y api limitations
scotto: shifting left, including Aria working group
<siri_> +1 scott
dont understand the need for a breadcrumb component
open ui is looking at other design systems as validation to make something
design system doesn't mean it is accessible
matt, priorities where poeple spend there time
browsers do things that are different from native context
multiselect listbox is example of hard to use
scotto: focus could be relooked at
bkardell_: good segway,
<sarah_higley> even beyond accessibility, I'd go as far as to say there are no multiselect listboxes that are even intuitive and easily usable in general
it should be noted that openui is part of wcig
many things that are part of investigations will not recieve a bunch of work
breadcrumb is a good example
a lot of breadcrumb components
like other standards body
onioning happens
<JonathanNeal> Related to bkardell_’s comment, here is a link to the OpenUI charter. https://
improvements are shared
high value things like select menu
microsoft/google intersted in solving
tabs is a different example
prefer to cal it panel set
protyping dev 1 years worth
tabs research is exemplary
not just screenshots
how that has been tried in markup
how it maps to html
chose to do a proposal
cuz it was kind of different
experience, feedback
jamesn raised concerns
no 1 path
<hdv> [ this 'starting from how people try to do things in the wild' approach is a huge benefit Open UI brings imo]
there are things that make sense to involve ARIa working group
not all
chrisdholt:
reinforce, research actual pain points
good example radio and radio group
browser extracts pain points
tagging system on our end
identified something to improve platform
<jamesn> qi+
<siri_> tabbing backward and forward is not consistent on radio group
<scotto> per chris's example of radio/radiogroup - hence my opening of this issue https://
how do we identify those items that are ready to move forward
need aria working group to be on board
for anything that has to do with controls
Matt, I like what you are saying
<bkardell_> to the question of how we work better together, I don't want to get back in the queue for this but I had expected (probably presumptuous) that some of the liasons _from_ aria were kind of on the lookout for what might be useful to bring up - we can easily come up with how to do better here I think
it would be good for us to go through open UI issues
and flag them as systemically problematic
that would benefit from addition focus for a11y
scotto and sarah can't do all the work
matt if I knew what tag to add, would love to add it myself for radiogroups
<hdv> +1, many/most of us in Open UI can flag accessibility issues, it's all of our responsibility
<bkardell_> +1
<chrisdholt> +1 ^
<hdv> (but in many cases we need your ARIA expertise to help find out what's right)
<siri_> +1 matt
<chrisdholt> hdv, bkardell - without prescribing should we open an issue or just pose a question on the Open UI side for creating a label there?
JonathanNeal: chairing open UI meeting today will bring up tagging
document how components exists today
interoperability is written into the charter
may not involve ARIA
it is descriptive
not
prescriptive
<hdv> +1 to JonathanNeal
<Zakim> jcraig, you wanted to reply to Chris Holt; mention benefits of low-barrier, low structure accessibility traits (as in iOS native) and to mention reducing requirements for rigid structure requirements whenever possible
jcraig:
reply to chris h
do we agree that it is tedius to enforce mutually exclusive elements to be inside the same container
?
aria working group needs to discuss
reduce rigid structure
to ease authoring
objected not allowing attributes not being used
or roles use limitation
aria container identifier attribute
like name attribute for html radio
<JonathanNeal> Here is a link to our OpenUI channel and our meeting today where I will bring up issue tagging for increased ARIA member involvement. https://
js framework patterns, element ref
frozen element array
instead of string reflections
pointers to other objects
like shadow dom components
all 2000 js frameworks
the way ios does a11y is different
then any other
led to wide adoption
most a11y structure is handled as traits
loose primitive thing
you can just apply traits
not enforcerd
<JonathanNeal> Are we still in overall group collaboration process, or have we moved onto gaps in ARIA which need filling?
api/AT does whats best when traits conflict
works most of the time just by applying traits
<bkardell_> "I like everything james said"
sarah_higley: to simple
too simple
<JonathanNeal> Thank you, sarah_higley. So much, thank you. I fully agree with you, and I regret framing my earlier comment as tho ARIA was not welcome during a descriptive effort.
it would be worth it to look at a way to mitigate act of defining patterns
to not perpetuate innaccessible ideas
<scotto> agreed with Sarah. identifying the accessibility gaps of current patterns would be good in the research description phase
bkardell_: what exists today is that
<hdv> +1 to sarah_higley , that research phase seems like a really good place to find a11y problems in what exists today
<chrisdholt> +1 to what Sarah mentioned as someone who coordinates w/ frameworks, etc
distinction between how they should be vs how they exist in the wild
sarah_higley: sees intention and different effect
add warnings to research
select merges many things
these are not the same thing
<chrisdholt> +1 Sarah :)
combining them has a11y implications
<Zakim> jamesn, you wanted to say that accessible web frameworks sometimes limit the things they want to do based on what can be made accessible
jamesn: there are many things wed like to do
bkardell_: looks at tabs research
we call out gaps
a11y charactertistics are unknown
<hdv> [ Tabs markup research: https://
<hdv> [ Tabs parts and concepts: https://
<bkardell_> jamesn: you can add me to that
<cyns> +1 to regular syncs
<bkardell_> sgtm
yes
<hdv> sounds good!
<aaronlev> +1
<Matt_King> +1 to syncing every 8 to 10 weeks
chrisdholt: everyother month seems good
<Zakim> jcraig, you wanted to consider codifying an ARIA API review expectations section? e.g. for every new ARIA feature proposal, has it been considered how it will be used in practice in popular frameworks patterns and new emerging technologies... eg. does this enforce more structure than it needs to? If there are rigid limitations, are they really necessary or just preferred?
jcraig: what if codified expectations
<bkardell_> that would be helpful
is this going to work with js frameworks, emerging technologies
propose solutions where needed
lightweight way to group elements
siri_: if you want to add new items
is there a process to do that?
jamesn: there is open ui research
jamesn: ?
<JonathanNeal> [ Radio Button Research: https://
siri_: radio groups, and scotts issue
jamesn: browsers change implementation
?
siri_: yes
chrisdholt: open issue articulating problem
dig in together
the delta is are we proposing something different
file bugs on browser if needed
different ideas
you dont have to have a prescribed structure?
<bkardell_> jamesn: I would love to get to the question about what to do about our current situation - I guess #8
<bkardell_> sorry not 8 I guess :(
start by filing bugs on browser
<JonathanNeal> I am interested in the #8 agenda item as well, jamesn. At least how we could follow up on that.
matt are keyboard behaviors specced anywhere?
no
if open ui is addressing keyboard behaviors what is the end result?
jamesn: there would be a new select element?
chrisdholt: we cannot break the web
matt, input type radio is not specified, open ui does not help with that problem
if you come up with a new kind of select
is the way that it gets specced?
<JonathanNeal> I do not wish to be rude, but may we please refocus on the agenda?
what would keep things interoperable
jamesn: aria actions can be native
sarah_higley: is working on it