W3C

- DRAFT -

ACT Rules Community Group Teleconference

25 May 2023

Attendees

Present
CarlosD, giacomo-petri, Wilco, Jean-Yves, dan_tripp, Helen, mbgower, kathy_, Karen
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Jean-Yves

Contents


<scribe> scribe: Jean-Yves

Visible label is part of accessible name https://github.com/act-rules/act-rules.github.io/issues/2040

Wilco: looking at 2.5.3.
... one example is "First name (required)" where the stuff in parenthesis might not be wanted in the accessible name (and is exposed through aria-required)

Mike: issue has been open that this duplicate information for AT users.

<Wilco> https://github.com/w3c/wcag/issues/3186

Wilco: this sound like the issue from last time with primary/secondary text in a button (where secondary text is maybe not needed).

<mbgower> Here are the PRs I have open on label in name https://github.com/w3c/wcag/pull/2725/files

Wilco: divided opinion on the issue.

Mike: 2.5.3 "text that is presented visually" is very subjective (is it label, punctuation, instruction, …)
... I am leaning toward letting these pass and have some "handwavy" language about what is the label.

Carlos: that aligns with the direction of our previous meetings.
... nice to see that AG is moving in the same direction.

<mbgower> https://github.com/w3c/wcag/issues/2302

<mbgower> https://github.com/w3c/wcag/issues/2276

Carlos:  parenthesis and "large cards" are somewhat different but related ("what is the label")

Wilco: "email (work)" vs "email (personal)" would need the content of the parenthesis to be in the name.

Mike: this is prone to personal heuristics to decide what exactly constitute the label.
... also, not everybody can locate labels in the same way (e.g. programmatically vs scrolling on the zoomed page)
... what speech user perceive as label is not necessarily the same as other user. Speech users also want to be succint.
... AT are also using a lot of heuristic (e.g. if there are 2 labels containing "name", they would number them and ask for more input, so "name" is a somewhat OK name).

Wilco: technologies seems to use both accessible name and actual text, making the SC a bit weak on its assumption.
... did ACT make an incorrect assumption that all the programmatic label always need to be in the accessible name?

Kathy: it gets very subjective to decide what needs to be in the name.
... the "secondary" text may actually be important in some cases (e.g. if two buttons subscribe to newletter with secondary text for different frequencies).
... considering the full programmatic label makes it easier to test.

Carlos: Sadly, WCAG definition of label is "the text that identify an element" and may be less than the programmatic label, as seen in some of these case. This also depends on the context (e.g. the secondary text is needed only if there is another element with same primary text and different secondary text).

Giacomo: (unrelated to 2.5.3) but when the button is an icon, user have to guess what the name is in order to activate it. Some AT let you split the screen and zoom on areas to activate any component.
... similarly, when the label and name do not match, users have to guess the name but are still able to activate the controls by other ways.

Helen: using a grid to focus on is not the best experience.

Wilco: "required" indication, or date format to input are real world example where the extra data is probably not needed in the name.

Jean-Yves:  should instruction ("required", format, …) be part of the programmatic label or not?

Helen: I usually recommend instructions to be out of the programmatic label.

Kathy: We had test results where one speech tool was only working with the name.
... how much of the visible label needs to be in the name for it to work?
... if you have two buttons, you'd have to say more to distinguish.

Carlos: if a minimum amount of text is enough to let AT identify the element, can we use that to write the rule?

Mike: there is no requirement that different controls have different name.

<mbgower> I am taking some actions from this to do with wording of the tests for both the general and failure techniques

Carlos: instead of comparing all the label text, we could search for only the initial part until it is different from all other programmatic labels on the page.

Mike: wording of the (failure) technique is very imprecise.

Wilco: alternative suggestion: we let the expectation be subjective, by looking for "the part of the label that identifies the control". Tools may use heuristics.
... it seems this cannot be tested automatically without heuristic anyway.

<mbgower> Supporting wording for the understanding document: "In order for the label text and accessible name to be matched, it is first necessary to determine which text on the screen should be considered a label for any given control. "

Wilco: the "thing that identifies the control" is the label in the sense of WCAG, no matter if the programmatic label contains more than that.

<mbgower> https://www.w3.org/WAI/WCAG21/Techniques/failures/F96

<mbgower> This is something of a research question: how much of a string match does there need to be between the programmatic label and visible piece of text on the screen before the AT can act?

<CarlosD> scribe+ CarlosD

<mbgower> +1

<CarlosD> kathy_: If the parenthesis information is at the start of the visible text would AT still be able to match the control?

<CarlosD> CarlosD: I would be more comfortable knowing the answer to what Mike just mentioned

<mbgower> me too

<mbgower> Wilco, can you remember who championed this SC?

Carlos: to do research, should we just ask users about their experiences, or should we actively build a list of examples with corner cases that can be tried out by people?

Helen: we should create the test environment.

Carlos: I can set up a test environment. I can use some help :-)

Helen: I can help.

Mike: I'll try to find out who championed the SC originally to better understand intend.

<dan_tripp> https://github.com/act-rules/act-rules.github.io/issues/1458

<Wilco> https://github.com/act-rules/act-rules.github.io/issues?q=is%3Aissue+is%3Aopen+2ee8b8

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.200 (CVS log)
$Date: 2023/05/25 15:03:15 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision VERSION of 2020-12-31
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: CarlosD, giacomo-petri, Wilco, Jean-Yves, dan_tripp, Helen, mbgower, kathy_, Karen
Present: CarlosD, giacomo-petri, Wilco, Jean-Yves, dan_tripp, Helen, mbgower, kathy_, Karen
Found Scribe: Jean-Yves
Inferring ScribeNick: Jean-Yves

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: 

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)


[End of scribe.perl diagnostic output]