W3C

– DRAFT –
MATF 12 March 2025

12 March 2025

Attendees

Present
AlainVagner, Jamie, Joe_Humbert, quintinb, RacheleD
Regrets
hdv, JonGibbins, TanyaVanWorkum, TimGravemaker
Chair
JJ
Scribe
Joe_Humbert

Meeting minutes

WCAG2Mobile Call For Consensus (CFC) in AG WG

@JJ providing an update on CFC, Title changed based on task force and larger group issue. After feedback, new title: Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)

<JJ> New title: Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile)

@JJ we may get more feedback from other chairs after CSUN. CFC shoukd go out next week (Wednesday) after CSUN

2.4.4 Link Purpose

w3c/matf#36

@JJ summarizing current guidance from WCAG 2.2 and WCAG2ICT

https://w3c.github.io/matf/#success-criterion-2-4-4-link-purpose-in-context

@JJ talking about "link text alone..." part might need some changes for WCAG2Mobile

@JJ talking about 2.4.4 Note 1 added in WCAG2ICT

@JJ going over previous comments on GitHub ticket

Jamie brought up the question about buttons that look like links

JJ reads off GitHub comment about what is a link and mentioned new link behavior with TalkBack. Also Actions from previous meetings about research around "link" behavior on native mobile

<quintinb> I think we need to define a link (e.g. interactive text). And add notes for touch target size, decide if formatting is going to be prescriptive (perceivable). Also, are we going to dictate what a link's behaviour should be?

JJ mentions Paul's comment about how to fail button for a link issue w3c/matf#36 (comment)

JJ talks about the target size exception for inline content (links)

RacheleD would like to definite what a link is on mobile. Cannot have an inline button

RacheleD talked about developers must make something inline a link because they cannot give it a role of button

<quintinb> I once told folks "You need to decide the business' incentive for clicking links, otherwise, keep not underlining links" - next day it was fixed

@JJ talks about his experience with adding links on mobile

Jamie asked about failure of 2.4.6

JJ said that if the visible text label is not clear it could be failed under 2.4.6 depending on interpretation, but "clear" is not defined

Jamie discussed around the wording of 2.4.6

<quintinb> If auditors are going to fail links on 2.4.6, it needs to be very clear that 2.4.6 applies to links.

JJ talked about a labels purpose and the definition of a Label in WCAG. And also that 2.4.4 is level A vs 2.4.6 is AA. Discusses link purpose

JJ talks about his experience with interpreting 2.4.6 and the more expansive definition of Label in WCAG

JJ talks about differences in WCAG around Label vs accessible name

<Jamie> I wouldn't;t think that 2.4.6 applies to identifying the purpose of links

ACTION: Figure out what elements have a "label"? Does a link have a label? Or is a link a control and not a label at the same time?

<quintinb> I am concerned that links get used as an excuse for deceptive patterns - "that's not a cancel button, that's a cancel link"

<JJ> label

<JJ> text or other component with a text alternative that is presented to a user to identify a component within web content

<quintinb> I think links in mobile should be far more well defined than for web

<JJ> w3c/wcag#4252

Joe_Humbert is a link considered a "component". The definition of Label uses Component twice

@JJ reads the response to the WCAG GitHub issues around "Component"

Joe_Humbert some of the instances of "Component" in WCAG are more abstract, particularly outside of SCs

Joe_Humbert if there is an exception for how a "component" is defined in WCAG it should have its own definition

<Jamie> +1 Joe to WCAG define "component"especially if there is the idea that 2.4.6 is sn exception

ACTION: We need clarification what would be considered a component within the label definition > https://www.w3.org/TR/WCAG22/#dfn-labels

Joe_Humbert please others comment on the github WCAG issue

ACTION: Comment/upvote w3c/wcag#4252 with areas that need clarification

Jamie talks about the WCAG2ICT added note for software and links (Note 1). Should we build off this note for our interpretation?

ACTION: Need clarification: "behaves like a hypertext link"

Jamie how is this task force defining links for native apps. The lay person "a link leaves the app, a button stays in the app" But is that definition accurate. Can we apply WCAG2ICT as written or do we need to modify or add another note of our own

JJ our guidance for 2.4.4 may be related to if links are covered under 2.4.6 because most companies try and meet level AA

Jamie is 2.4.6 intended to mean visual purpose and 2.4.4 is the trait purpose

JJ talks about single page apps and how the intended purpose of links and buttons are becoming blurred with newer implementations because both are used for navigation to other Views/pages

JJ if buttons have issues with clear purpose they might fail 2.4.6

Jamie mentioned questions around tappable titles and description or purpose and if these might fail 2.4.4 or 2.4.6

JJ maybe a note to clarify what our task force views as a link or modifying Note 1 from WCAG2ICT. possibly only keeping the first sentence "In software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link."

@JJ mentions the new added note for 2.4.6 from WCAG2ICT

JJ we may need to definite headings and labels for WCAG2Mobile, suggesting this approach

JJ 2.4.4 and 2.4.6 are more closely related then we realized

Jamie do we have an actions from the long conversation about 2.4.4/2.4.6

JJ we should make a draft of 2.4.4 and 2.4.6 and bring it back to the group

<JJ> 2.4.4: apply as written in WCAG2ICT, but add note to clarify "hyperlinks" in mobile apps

<JJ> 2.4.6: apply as written in WCAG2ICT, add note 1 to clarify "heading" in mobile apps and note 2 to clarify "labels" in mobile apps (mentioning buttons have labels, links have labels, etc.)

<JJ> Reply with +1, 0 or -1

<Joe_Humbert> +1. I think the drafted content will bring more feedback

<RacheleD> +1

<quintinb> +1

<Jamie> +1 but also add a note to 2.4.4 about whether it applies to buttons

<JJ> 2.4.4 add note 2 to mention it's a best-practice (or requirement?) that all controls/components that are used to navigate also conform to the requirements of 2.4.4

<JJ> consider that link purpose is not a 'best-practice' but requirement for links but also for those other kinds of components that navigate

Jamie should the change to 2.4.4 around "components" be more than a best practice (covers other controls)

Joe_Humbert would adding other components tp 2.4.4 go beyond the current scope of the WCAG SC, 2.4.4

JJ it is not difficult to apply the requirements to other controls

Joe_Humbert I do agree with expanding the definition

Jamie yes we can because this is a different platform, that is part of the purpose of this group

JJ thinks it is worth trying to see what feedback we get with this change for 2.4.4

<Joe_Humbert> +1 to what Jamie and JJ said about expanding 2.4..4

2.4.6 Heading and Labels

JJ other SC might be ready for drafting

<JJ> Heading and Labels was discussed in previous item 2.4.4 because they are linked

JJ 1.3.3 is ready to make a draft. 2 SC are ready for drafting now

JJ next week discussion: 2.5.1 Pointer Gestures and 2.5.2 Pointer Cancellation. other agenda items will be added. Hopeful for more rough drafts

Summary of action items

  1. Figure out what elements have a "label"? Does a link have a label? Or is a link a control and not a label at the same time?
  2. We need clarification what would be considered a component within the label definition > https://www.w3.org/TR/WCAG22/#dfn-labels
  3. Comment/upvote w3c/wcag#4252 with areas that need clarification
  4. Need clarification: "behaves like a hypertext link"
Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Active on IRC: AlainVagner, Jamie, JJ, Joe_Humbert, quintinb, RacheleD