Meeting minutes
2.5.3 Label in Name proposal
2.5.8 Target Size (Minimum)
2.5.3 Label in Name proposal
<pauljadam> I would worry about allowing people to code "secondary labels" in something other than the a11yName property.
<pauljadam> even if the visible label is very large, then it should all be in the name still
<pauljadam> on iOS native you don't even have an accessible description property, we only have the Hint which can be turned off
<pauljadam> so you have to shove everything into the .accessibilityLabel
<pauljadam> define "other accessibility properties" the WCAG SC is called "Label in Name" so they are specifically saying the a11yName
pauljadam: The WCAG is called "Label in Name" - how can we allow anything in except in the name
pauljadam for VoiceControl we just want the first word shown. But it's not relevant to this success criterion
pauljadam the way to avoid putting everything in the name is to separate the components. If you put it in the hint and they have hints turned off. I've seen weird things like put things in the value. The label is pretty much all you have
contentDescription, stateDescription, roleDescription are what available (off the top of my head while scribing)
RobW on user input labels - they're not just for Voice Control, they can be used for Keyboard - which is why you want all the text. What I would use a value for - possible disagreement - if you have something not editable, then you might put the label as "Downloads" and the value "# of downloads"
pauljadam you can code it like that but we don't have that on web
pauljadam the success criterion does clearly mention "name"
pauljadam if users have hints turned off - is this written for testers or developer or both?
pauljadam Voice Control users can use the numbers if the name isn't working
<RobW> +1 to removing the second sentence from the first note.
<pauljadam> I like the a11y actions note
RobW no objections on the last note. On the 2nd note I have mixed feelings, I agree with Paul that we should not encourage hiding information because of a hint. I don't want to make auditors feel that they should fail because not everything is in the label
<pauljadam> I think the best practice about the label first in the name should talk more about how if the name is not first then voice control wont see the first word of the label, like if you put the label in the middle or the end of the name then they will see some other word in the Show Names feature
<JJ> Poll: For 2.5.3 first note, do we keep the added second sentence ("This is particularly important for voice control users who rely on speaking the visible text to interact with user interface components.") or omit it?
<JJ> +1 to keep it, -1 to omit it
<pauljadam> -1
<quintinb> -1
<RobW> -1
<sam_e> -1
<Tanya> 0
<Joe_Humbert> -1
<tayef> 0
<JJ> Poll result: 5x -1 and 2x 0 -> leaning towards removing the 2nd sentence
pauljadam we might want to talk about how "show names" operates for Voice Control and how this is a usability enhancement.
Joe_Humbert we need an iOS specific example in the note
<Joe_Humbert> don't need*
Thanks Joe_Humbert! My bad
<JJ> Poll: For 2.5.3 second note, do we keep it (+1), remove it (-1) or modify it (0 with comment)
<pauljadam> -1
<quintinb> -1
<Joe_Humbert> -1
<RobW> 0 - needs more thought.
<Tanya> 0 - note sure
<tayef> 0 not sure
<shoobe01> 0 (worried I misssed too much of the argument to remove being late)
Joe_Humbert why do we need this note at all - we're being more prescriptive than we need to be
<JJ> Poll results: 3x -1 and 4x 0 -> mostly leaning towards removing it or thinking about changes
<JJ> Poll: For 2.5.3 third note, do we keep it (+1), remove it (-1) or modify it (0 with comment)
<pauljadam> +1
<quintinb> +1
<shoobe01> +1
<RobW> +1
<Joe_Humbert> 0
<sam_e> + 1
<Tanya> +1
<tayef> +1
<JJ> Poll results: 7x +1 and 1x 0 -> mostly leaning towards keeping it as is
<pauljadam> last note makes sense because it's not saying anything that goes against WCAG, it's basically explaining how you can use a11y actions or have separate CTA controls
<pauljadam> Remove the nested part
<pauljadam> just say separate
Joe_Humbert - I am worried about saying nested controls - we don't want controls inside others as it create problems. It can easily break touch target size
<JJ> Labels of controls may be exposed as custom accessibility actions
<JJ> (e.g. seperately focusable elements being allowed is implied because thats always allowed)
Joe_Humbert I see a11y actions are to make additional actions on one control
I have seen this for "card" behaviour where the card does the main thing, and then there are "sub" actions
Music player: Play the song, actions: add to list, favourite, etc
Joe_Humbert my worry is that name is that there would be lots of repition
*repitition
"Queen: Another one bites the dust. Button. Actions available"
pauljadam Maybe the whole card is tappable with smaller actions / buttons - do the actions need to be part of the card? Do you need to cycle through the actions in order to discover them?
pauljadam some cards are split into many components - maybe we need to re-word based on what we're expecting
ooof - I'm glad I'm not at Spotify anymore!
That would make the card state super complex
"[Song] Selected, Favourited, On a List"
<RobW> does 'sub controls' work? Implying a control related to the parent, rather than a more generic 'nested'.
<pauljadam> sub control sounds good
2.4.2 Page Titled proposal
<pauljadam> or we could just say a11y actions or actions
<shoobe01> An all encompassing row/card with sub-actions is IME very dangerous. I avoid it always, if this discussion was style guide/designsystem I'd argue to ban that but... I know we cannot. "Subordinate" def discussion then is interesting.
<JJ> w3c/
<JJ> Page definition: https://
Tanya I just added the latest comments of Joe and Steven and processed - nothing to add
pauljadam Where it says "a visible title is not feasible then it's not required" - I don't know how to code an invisible title. There is a navigationTitle property - there are programatic property that exposes a heading. I also worry that its a best practice to mark it as a heading semantically because that almost seems like a requirement
pauljadam you can't make a title on the web invisible - it's always visible though
pauljadam if we're worred about modal because they aren't pages
<shoobe01> No!!!!
pauljadam I think the heading is more important in apps - could a non-heading label be accepted as a heading, but we always check that
pauljadam I feel that Android should make it a heading semantically
shoobe01 Almost every design product team that a dialog is contextual to the page but even for sighted people it's not. How fixed is this?
<pauljadam> shoobe01 are you wanting a visible title for a dialog or an accessible name for the dialog? or both?
shoobe01 in general I think it's best practice to mark it as a heading
<pauljadam> Because on iOS you can give a11y containers an accessible name so you can have a dialog with an a11y name if you want and also give the dialog a visible heading if you want
<pauljadam> Not sure it's critical to be a heading but critical to be visible.
Joe_Humbert I disagree that the page title needs to be a heading - this is just about the visible text
<pauljadam> usually though titles of sections of content become headings
Joe_Humbert in iOS this is an apple convention that can change.
Joe_Humbert I agree it should be best practice
<pauljadam> heading requirements can go under headings SC is fine
<pauljadam> I don't think invisible is allowed
<pauljadam> top of the page makes sense but then you may have tab bar based app where the selected tab could be a title yep
3.1.1 Language of Page proposal
<JJ> Have a look at: w3c/
2.5.7 Dragging Movements proposal
<JJ> Have a look at: w3c/
2.4.11 Focus Not Obscured (Minimum) proposal
<JJ> Have a look at: w3c/
Software layers
<JJ> Have a look at: w3c/