Meeting minutes
New Issue Triage
spectranaut_: w3c/core-aam #165
scotto: move to html-aam
… there's already a PR there.
jnurthen: should we just close with link?
scotto: sounds good.
<scotto> w3c/
spectranaut_: will do
… next w3c/aria #1877 another from Anne
… about tooling
pkra: assign to me for the chairs meeting
jnurthen: yes, editors' issue
spectranaut_: next w3c/html-aam #461
scotto: it's a clarification
… I'll make it clearer, help to connect the dots
spectranaut_: w3c/aria #1875
… on agenda
New PR Triage
spectranaut_: w3c/aria #1876
… mixins
… upstream is merged
… we can un-draft it again.
jnurthen: can we ask Alice?
spectranaut_: yes!
jnurthen: cynthia would also be a good reviewr.
… will also ask in AOM meeting.
spectranaut_: next up: w3c/aria #1873
ari: there was already some discussion.
… 1-9 seems fine across the board, the rest a bit iffy
mattking: I thought 8 was the limit.
spectranaut_: jawsTest did a bunch of testing
… JAWS struggling with greater than 6
jnurthen: it's not a browser problem.
mattking: sounds like an ARIA-AT test in the making
spectranaut_: PR limits authors to 6
mattking: so then just like HTML
spectranaut_: more because every browser+AT combo supports it.
… pkra and scotto suggested that it's more a browser / AT bug
scotto: I didn't suggest a limit.
pkra: me neither
<melsumner> I think we should support what HTML does and not do more than that.
scotto: [channeling jcraig a bit]
mattking: it's a structuring problem of course.
… no way to navigate with AT etc
… if we align with HTML, then we only go to 6.
pkra: I feel like while it's a bad idea, we would be breaking existing implementations. Stopping at 6 when there's more that's supported seems unnecessayr
mattking: use cases?
scotto: I recall a code editor
pkra: I know use cases in publishing.
… but they are niche and practically frequently rewritten
spectranaut_: maybe we should talk to browsers and AT about the inconsistencies
<jamesn> if we were to change would need to file a WCAG issue https://
scotto: maybe the PR should add a note that best practice is 1 through 6, the problems with going beyond it.
… e.g., number keys in AT
<jamesn> https://
mattking: e.g., VoiceOver has a "find next of same type" which would theoretically work.
scotto: and just H key would not skip.
mattking: I like the idea of a note.
pkra: +1
jnurthen: I added a link to a WCAG technique referring to level 7./
spectranaut_: could aria-at help here?
mattking: yes, we could do that.
… it could get AT to support the level we want
melsumner: the wcag documentation is a made up example so I feel that should be abel to change
… it's a cognitive issue. 6 levels are too much.
… we should not support problematic use cases.
mattking: would the note be sufficient? If there's a specific use case, then why deny it?
melsumner: there's a difference between what's allowed and what is a good idea.
… allowed becoming an escape hatch
StefanS: this is potentially related to other number dependent properties, e.g., aria-level
… no theoretic limit but cognitive one.
spectranaut_: APG exists for more specific guidance.
… Ari opened an issue there beforehand.
… jcraig, scott added that sometimes there are edge cases that are still usable, based on usability research. Not sure we should limit that.
… if there's a book, e.g., art or poetry, then perhaps that's something that works.
… in a "regular" situation, this is not what authors should do.
jamesn: I also think we should limit ourselves to technically possible. E.g., legal documentation is such an example.
… e.g., documents as a single page in shorter form, then lower level headings, but combined together it has additional levels.
scotto: even wcag is vague sometimes about what's good. e.g., keyboard navigable does not have to be "good".
… which is why we should have a note to make it clear what is good practice vs what's technically possible.
ari: I will work on a note.
StefanS: so this feels like APG territory, including aria-level.
… so heading maybe up to 7, maybe trees are different etc.
Deep Dive planning
spectranaut_: mininum role next week
… then continue to discuss secondary actions at F2F
<jamesn> https://
F2F Planning - May 3/4 in Seattle, WA - host Adobe
jnurthen: please re-check deep dive meeting details - they have changed.
spectranaut_: F2F planning.
jnurthen: there's availability for a room at Adobe.
… wait with flights until we have confirmation
spectranaut_: remember to add F2F candidate label on PRs and issues when you want to discuss those
… it's important for people to decide if they attend
mattking: are there issue marked for longer workshop-like sessions?
jnurthen: not yet.
… maybe openUI
… more thoughts on fixing tables.
… I would like those but nothing firm.
<melsumner> +100 to tables
mattking: any information on accomodations around the location?
jnurthen: I think it's not ideal.
sarah_higley: fremont neighborhood. lots of restaurants etc around it. good bus connections.
should aria-expanded be allowed on searchbox and textbox? #1875
jnurthen: seemed like a spec inconsistency.
… searchbox and textbox allow auto completion
… but aria-expanded is not allowed.
… should it be allowed? Should auto-complete only be limited?
mattking: an interesting conundrum.
… on a search box, it becomes a kind of combo box. primary use case for text box is probably type-ahead.
… doesn't make sense for single line text box, then it's just a combo box.
scotto: we had some discussions with product team. They wanted to do this but we suggested combo box.
… search box is another example. Usually you get "search, search box".
… so we were wondering about the functional difference.
… does it really need to go on a search?
<siri> usually search boxes that provide suggestions are marked up as combobox
scotto: e.g., ghosting autocomplete, hitting tab to complete, should that really be a combobox?
sarah_higley: adding to that. From usability studies on combo-box. people expect to pick from options, not a lot of people start typing.
… especially screenreader users responded that they didn't expect they could type.
… despite scenario descriptions that might have hinted at it.
… combobox is not the most useful role for a search box.
… feels like expanded is the one thing that's missing. everything else is there.
… then content editable situations isare another example that's not a combo box.
mattking: need a purpose for search box role; specifying, what it really is.
… html select maps to combo-box when size is 1.
… in OSs there's been an editable combo-box for a long while.
… very differently announced, too.
<scotto> <input list=foo><datalist id=foo> ... </datalist> also maps to combobox.... but this has been a rather problematic pattern for some time, and people don't often like it because the datalist can't be styled
mattking: to make a text box with all the features of combo box is just that but announced as text box.
… that would force AT to announce all properties to make users aware
sarah_higley: free form box was throwing people. The fact that they could type something that wasn't in the suggestions.
mattking: interesting. maybe it's more appropriate to say it's a text box in that case. E.g., VS Code in the search field, it's actually a multiline text field.
… when you write a long regular expression, it wraps.
… you can move outside it and it might change to previous search.
… I don't think aria provides a good solution to that.
Adam_Page: examples I run into is type ahead vs results presented as list. was search box role suggested to cover both cases?
siri: we have different types of combo boxes, e.g. as adam mentioned.
mattking: I feel we haven't decided what search box is
… e.g., search in iOS doesn't work like typeahead but you might see a list of suggested results. It doesn't have an equivalent to expanded/collapsed in iOS.
… I don't really know if the role search box is valuable to AT users or not.
… if we tried to make a distinction, I'm not sure those are going to end up helping users.
… I always feel fewer roles are better.
… then explain what it does to users.
… more roles risk more confusion.
sarah_higley: in theory I agree, in practice I found when allowing free text input and suggestions, combo box is not the best solution for end users.
… so feel like allowing it.
… textbox I find more difficult.
… primary use case seems to be a multiline input.
… that implies to authors they can remake the combo box role witout combobox
… seems like edge case for text box but main case for a combo box pattern.
… if we don't allow it - since we already have active descendant - I feel either both or neither.
mattking: but in multiline is not expanding something, right?
… the span that triggers the expansion is the thing that is expanded. not the parent text area.
… that feels hard to solve.
sarah_higley: but the focus is on the parent.
mattking: but caret is inside
sarah_higley: almost as if the web wasn't designed for editable documents ;-)
jnurthen: I'd love to find something useful to do for search box.
… seems like nobody knows something useful to do with it.
scotto: if you put expanded on it, NVDA turns it into a menu-item.
spectranaut_: are there next steps?
mattking: feels like we haven't done this because the other use cases are a bit undefined. free form text input where something inside triggers popup
… is something we don't have a solid pattern for.
… maybe approach this from use case perspective instead of starting from aria.
jnurthen: we should just solve 1 or 2. The it's at least useful.
… something for openUI perhaps, too.
RRSAgent: make minutes