Meeting minutes
Interactive Lists Overview status and next steps
ISSUE: w3c/
<jamesn> https://
Marcelo_Paiva: yesterday we talked about list views and dashboards and cards. I think we could get a new role for this
Marcelo_Paiva: the lists have different features in different view types; for example in Windows file explorer and in MacOS finder, there are different ways to view different types of lists
<Marcelo_Paiva> @melsumner correction on the speaker: Mario instead of Marcelo
apologies, will fix
Mario: we have to change the display type of the role now and that's not useful/good
Mario: so Sarah and Stefan have suggested listview as a complex role
Mario: in the listview there are different child roles: listeviewitem, group (to group listviewitems) and featureheaders, a container for featureheads for detailed views
Mario: there are also different proposed listview attributes
Mario: and the next steps are to think about filters (how can they be semantically connected to a list view)
Mario: and keyboard navigation
sarah_higley: clarifying question: what are featureheads
Mario: labels for features that are mostly displayed in details but could be used in other view types
Mario: same as columnheaders
sarah_higley: I dropped my thoughts in the issue (issue number...)
sarah_higley: my thought was that these kinds of lists would be more like grids, more complex widgets to allow navigation inside and around the widget
<Matt_King> fq+
sarah_higley: 2-dimensional vs 3-dimensional ?
sarah_higley: open questions: should there be a specific listview type? do we need to have that?
sarah_higley: platform accessibility mapping is also an open question but native apps already do this
sarah_higley: should selection be allowed but then how do we differentiate from listbox
sarah_higley: should this be a different role or inferred from how it's being used
jamesn: I think it should support selection
<Zakim> jamesn, you wanted to ask what roles these listView items have for the native versions?
jamesn: if we don't support selection it would cause problems, most use cases need to support selection
jamesn: how we differentiate from listbox ....naming will be important
jamesn: will this thing be supported within a combobox? I say no but it's possible someone will think to try it
StefanS: I've shared my screen, I think everything that Mario said is good
StefanS: (demonstrates some UIA)
jamesn: can you share a screenshot here?
StefanS: I don't know how to do that but I will do some homework and share it later
StefanS: from what I'm showing, there is continuous numbering
StefanS: we can switch from a "grid like" view to an icon view and there are no more rows; and Microsoft has been doing this for a very long time and no one is confused
StefanS: looking at a tile-based layout, showing that users can navigate left/right, up/down in and around the tile group
StefanS: a listview model would help improve situations where we have nested interactives in listitems
Matt_King: I'll keep it short and write longer thoughts in the issue.
Matt_King: it's great that there seems to be a lot of need for this but there are some places where we need some clarification
Matt_King: listbox has a value; listview would not have a value, that's one way to easily distinguish
Matt_King: a listview doesn't really have anything like it in HTML today
Matt_King: we should be careful to avoid making listview into a gridview but I don't think that part is complicated
Matt_King: do we really need a listview type? I think this is a fundamental question
Matt_King: if we have the browser automatically calculate set size, position in set, they need to know how many there are. but does it need to?
Matt_King: SR users probably don't care what's in the listview so I don't think we need to worry about what the content is. That's up to the author
Mario: disagree
Matt_King: if you have cards, no matter what's in them or what size they are, the navigation should not change.
Mario: the role should stay listview (in windows)
Matt_King: in ARIA the role should not stay listview, it should be gridview for something like windows explorer details view
Matt_King: a grid is a grid and a listview is a listview and we gotta be careful and not cause chaos
sarah_higley: 2 things
sarah_higley: to the point where folks might use listview for selections in stead of listbox I wonder if this will be a good thing because the current state of things...kinda sucks
sarah_higley: 2-dimensional thing: we should not support column headers on a list view and I agree with Matt King that there's a difference between the gridview and the listview
sarah_higley: I don't think we should be taking the list control type in Windows and bringing it forward because that's not even how Microsoft is bringing it forward
sarah_higley: the list-grid hybrid does not exist and (shouldn't?)
sarah_higley: so sharing that context so we can all understand it
<Zakim> Mu-An, you wanted to say clarifications on definition on 2-dimension interactive list, for example- github issue list view
Mu-An: the grid vs the listview seems confusing to me
Mu-An: I'd love to see an example for how these are supposed to be used so I could better understand what this should look like
Mu-An: I'm also confused about the featureheaders and features? Wouldn't this make them column-like?
Mario: if we stay with grid for details list, then we don't need any feature roles, that's clear
jamesn: next steps will be in the 1.4 prioritization session
Relationship with ATs, and update on ARIA-AT results
<spectranaut_> to join remote: https://
<spectranaut_> this one: https://
Matt_King: i want to show examples of test and show an overview of where the project is
… we're looking at a staging server, on the aria AT website
… developing interoperability testing for screen readers, current focus on jaws, nvda on desktop
… get to voiceover and talkback by end of this year
… the project has 2 buckets of work. 1. is writing the tests and manually running them. 2. how will we keep the report for those tests current whenever a new screenreader is released. we're developing AT driver. we would be able to use to drive screen readers in the browser context
… automate the work with the drivers
… if test results are different, the driver can flag humans for review
… here's a table of tests. this is for voiceover in a radiogroup
… these are fairly granular tests.
… we test with different commands.
… I want to give a brief overview of this table for our process. similar to w3c spec process.
… we draft a test plan. and members of our wpt group can write and review these.
… once we have buy in from our screen readers, we go ahead. we're testing all patterns in the apg. so there are 35 plans in this table.
… this is how we're managing the data.
… we're in a big state of change. we have changes coming out for the app. and we're refactoring how we are writing tests. we're incorporating feedback. made some simplifications and improvements ot eh way we write tests. it coming out over the next couple of weeks.
… the specific proposal I have is. we were talking about aria notifications yesterday. there would be a prototype. we would put a copy of that prototype in the repository for these tests. we would figure out how testable it is. we want to define minimum AT behavior. we don't have to have something in the apg to have it in the test cases here. we should have functional examples.
… stylized as experimental
jemma: 2 questions: 1. what is r and d version mean?
Matt_King: the version of the test plan that has been written but not reviewed.
… if we get feedback in candidate review, we would develop a new version. and that new version number would show up in the r and d column.
jemma: 2. driver is for new aria features, aria-notify, etc. how are we gonna figure out the testing for newer features?
Matt_King: we would submit the new examples for the community group.
daniel-montalvo: congrats on the work you're doing. I appreciate it.
… feedback from screen reader vendors -- is that trackable?
Matt_King: yes its in the aria at repo. they provide feedback by raising a github issue.
steve faulkner: thanks Matt_King for getting the process going. its been a positive process so far.
Matt_King: one of our challenges right now, nv access does not have the resources to keep up with this.
StefanS: question: where do these labels come from?
steve faulkner: though testing, i file a bug, and that gets pulled into the internal bug tracker
… through this effort we are getting more activity.
StefanS: this process should be automated somehow
Matt_King: you could have one small bug in radiobutton for example. just one bug was causing multiple test failures. but someone like steve can see that it was one bug that caused all this issue.
… hard to automate how to find/report the bug
lola: wednesday, i'll be giving a presentation on the at driver
… you're welcome to join
spectranaut_: when we have a new proposal, like aria-notify, you want an example implementation?
Matt_King: yes, and we will be asking questions to get the tests written
… the sooner we can do think about the tests, we can make sure the new feature has its intended effects
jemma: these test results are going to be a part of the apg page?
Matt_King: we wouldn't surface this on the patterns page. the test results would show the support level but people aren't used to checking that. these are unreleased features, they wouldn't show on the patterns page
jamesn: and these features should be marked as experimental right?
Matt_King: correct.
1.4 Prioritization
ISSUE: w3c/
<jamesn> https://
jamesn: I've created an ARIA 1.4 project that everyone should have access to
all the issues in the 1.4 milestone... all 149 is obvs unrealistic
I closed 24 of this in triage on the plane
there are probably more we can close
this groups the issue by assignee
ACTION: for all: look through your assigned. verify you agree with the assignment, labels, etc.
<Jem> https://
currently 40 or 50 unassigned non features
should any of these be features?
for example, can we close the role-parity issue for inputs... did we ever agree that these should be reserved native?
jcraig: the html input type ones may be address by an HTML-AAM open Issue/PR
StefanS: can we close ones that are no longer relevant?
jamesn: would like to keep the html form element issues open until the testing mapping is done
<Jem> jcraig: May be Scott have PR for role partity issues.
jamesn: so everyone please review your assigned issues and suggest keywords, priority, milestone, or other paths forward, etc.
* group discussion about the github view *
<jamesn> https://
jamesn: this is the link without the assignee grouping
90 issues
assignees, if you're not planning to work on this in the next year, unassign yourself
this is not the priority list for 1.4... this is jut the triage list.
<jamesn> ### Major Features
<jamesn> * aria-actions
<jamesn> * listview?
<jamesn> * notifications (not ARIA but will require re-work of ARIA implementation)
<jamesn> * data Visuzalization?
<jamesn> * Label Synonyms
<jamesn> * Virtualization
<jamesn> * "interactions"
<jamesn> - 4-way picker
<jamesn> - direct interactions
<jamesn> - sub-element click target
there are 34 I identified as features..... We will not go through all today...
but these are the major features
Jem: does this mean including implementation?
jamesn: yes, everything that it takes to get it into the spec
aleventhal: + deprecatable issues, like aria-relevant
jcraig: aria-actions?
group: yes
jamesn: aria-actions?
jamesn: listviews?
group: yes
<spectranaut_> link for listviews: w3c/
jamesn: notifications... incubator
group: yes
jamesn: dataviz? I want this... not convinced it's 1.4
jcraig: agree it's too soon to say 1.4
aleventhal: this is a separate subgroup incubator, right?
jamesn: 2024 investigaiton? 2025 feature?
group: yes, sure
possible moving aria from Rec track to Evergreen
snap shot every 2 years or so
features go in to the spec only when ready, complete, and implemented
aleventhal: it's more difficult to implement from a PR than from an editors draft
can take years to get ARIA features all the way through AT implementation
jcraig: could work as long as there is a viewable spec with experimental issues?
a/aleventhal: /aaronlev:/g
aaronlev: might be unrealistic to say "it's supported" in the browser until you can verify it works in most AT
Matt_King: need more engagement from AT vendors
jamesn: label synonyms
<Zakim> melsumne_, you wanted to say we could consider adopting stages
melsumner: stage 0 would be proposal stage... implementation is stage 1... etc. Recommendation at the end
jcraig: label synonyms needed for Voice Control... not sure if Dragon or Windows dictation has similar, presumablly yes but we need two implementations... so 2025?
jamesn: virtualization?
group: 2025.... notificaitons is higher priority, and testability is a prerequisite
jamesn: 4-way picker... e.g. 2D slider
Matt_King: needs API for 2D slider... should punt
jamesn: punted... would we ever do it?
jamesn: put the 2.0 flag on it.... e.g. "not soon"
<Jem> two dimensional slider issue at apg w3c/
direct interaction?
https://
<jamesn> w3c/
aria-directinput: [ undefined | direct ]
Matt_King: signal to AT to handle this...
<jamesn> w3c/
aaronlev: worried about prioritzing b/c Windows AT don't yet need this
Marcelo_Paiva: Are there aria gestures?
jamesn: no
e.g. aria-hitpoint
discussion of issues explained in w3c/
2025
jamesn: any other priorities
aaronlev: aria-hidden fixes?
jamesn: only counting larger features
Matt_King: what the the bigger version of aria-modal?
jcraig: how is this different from aria-modal?
aaronlev: this is about keeping focus in aria-modal
jcraig: that's how VO implements aria-modal today.
jamesn: would others helping out keep this on the 2024 priority list?
aaronlev: other implmentors
jcraig: what about dev tools warnings as a spec feature?
jamesn: that's mostly editorial... not a user feature
Slides... https://
disregard. wrong channel.