W3C

– DRAFT –
MATF October 23 2024

23 October 2024

Attendees

Present
GleidsonRamos, Jamie, jeroen, JJ, Joe_Humbert, julianmka, Karla, quintinb
Regrets
-
Chair
-
Scribe
quintinb

Meeting minutes

Yup!

3.2.6 Consistent Help

<Joe_Humbert> w3c/matf#43

I know for example "COMMAND + /" in Android show the keyboard shortcuts, and developers can add their own shortcuts to this menu if they programatically register them

⌘ + /

julianmka I agree can apply as written with minor word swaps - however floating chat also needs to be considered, like a chatbot

julianmka usually floating actions present other accessibility problems on top of consistent help

Jamie I feel like including floating help as an additional option or note should exist, not to modify the SC but acknoledge. Looking at the NOTE 3 (ADDED) how does it apply? Does it need to be a set, or just a pattern?

I would consider the floating help toelong to this

*to belong

<Karla> +1

Joe_Humbert some of this needs to defined at a higher level to avoid the document being overwhelmed. The floating help seems to cover many of the points

<Jamie> -1

@joe asking if there is something to call out specifically? *silence*

<quintinb> +1 Joe_Humbert to adding this to understanding

julianmka we should not conflate the SC too much (like with the keyboard android stuff)

<Jamie> +1 to julianmka

<quintinb> +1 julianmka

<quintinb> +1 to keep as is

"view" needs some clarity

<GleidsonRamos> +1

but yeah

<Jamie> +1

<Karla> +1

<julianmka> +1

ACTION: Propose the draft SC as is for wider group

3.3.2 Labels or Instructions

We could probably add a note that labels should not disappear when input focus is given to the labelled element (i.e. hint)

<JJ> Hey all, sorry for being late - construction workers started making noise at the office so headed home, but missed the meeting notification because I was away from my laptop. Thanks for taking over Joe_Humbert!

Could we just add a relates link?

Joe_Humbert it seems that mobile developers do miss this

julianmka said there is a mention of this somewhere else

Jamie if we scope it to mobile apps, agrees

<JJ> Yes, note can help to clarify best-practices in mobile (app) context

Just add a contact in iPhone - the name field is an example of this error

julianmka there isn't a mention in 3.2.2 in the understanding docs

Joe_Humbert do we need to modify the definition of label?

Android would be "text" element, "UILabel" in IOS

(or "TextView" if you're a dinosaur Android dev)

<Jamie> +1 as is

<JJ> +1 as is

<quintinb> +1 as is

<julianmka> +1

<GleidsonRamos> +1 as is

<Karla> +1

ACTION: Suggest to accept 3.3.2 for the wider group

4.1.2 Name, Role, Value

<Joe_Humbert> w3c/matf#48

<JJ> Fixed link in agenda

Jamie on 4.1.2 - 2 questions: intended coverage - to all UI element types, and how to call out keyboard as an AT for 4.1.2

Jamie How do we interpret the control aspect?

I would say that all UI components regardless of interaction should be identifiable by AT

JJ I've interpreted this in the context of interactive components - the issues are mostly about custom components

julianmka I think there is a world where this primarily applies to custom components, native components usually work but devs do lack a lot of knowledge in this area (e.g. separation of name and state).

GleidsonRamos I agree about custom components, but not always - in X platform there are additional issues because a lot of the time the components that are "standard" are actually already "custom"

<Jamie> +1 to julianmka that even standard user interface components in mobile do include a higher layer of accessibility knowledge than in web so should be mentioned in this SC

bye!

Summary of action items

  1. Propose the draft SC as is for wider group
  2. Suggest to accept 3.3.2 for the wider group
Minutes manually created (not a transcript), formatted by scribe.perl version 238 (Fri Oct 18 20:51:13 2024 UTC).

Diagnostics

Active on IRC: GleidsonRamos, Jamie, jeroen, JJ, Joe_Humbert, julianmka, Karla, quintinb