23 February 2023


arigilmore, CurtBellew, Daniel, jamesn, Matt_King, melsumner, pkra, sarah_higley, scotto, spectranaut_, StefanS

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/html-aam#446

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://www.w3.org/TR/WCAG20-TECHS/aria#:~:text=ARIA%20Techniques%20for%20WCAG%202.0%201%20ARIA1%3A%20Using,role%20of%20a%20user%20interface%20component%20Applicability%20

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://www.w3.org/WAI/WCAG21/Techniques/aria/ARIA12

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://www.w3.org/events/meetings/e957ab02-020d-4e5d-9f31-65505f8b1d82

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

Minutes manually created (not a transcript), formatted by scribe.perl version 210 (Wed Jan 11 19:21:32 2023 UTC).


Maybe present: Adam_Page, ari, jnurthen, mattking, RRSAgent, siri

All speakers: Adam_Page, ari, jamesn, jnurthen, mattking, melsumner, pkra, RRSAgent, sarah_higley, scotto, siri, spectranaut_, StefanS

Active on IRC: arigilmore, CurtBellew, daniel-montalvo, jamesn, Matt_King, melsumner, pkra, sarah_higley, scotto, siri, spectranaut_, StefanS