search

w3c / matf

Guidance from the Mobile Accessibility Task Force (MATF)
https://w3c.github.io/matf/
Other
8 stars 3 forks source link

Success Criterion 2.4.6 - Headings and Labels - Level AA #50

Open JJdeGroot opened 4 months ago

JJdeGroot commented 4 months ago

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#headings-and-labels

Share your thoughts for applying to mobile apps as a comment below.

Keanem6 commented 3 months ago

Could there be an argument to request each view (or screen) have a heading at the top of content to indicate and describe the start of main content. This might perhaps overlap with 2.4.2 Page title depending on what we decide there, but i think it's important to define each view with a heading - which i could be mistaken but no other success criteria seems to point to.

julianmka commented 2 months ago

Requiring a heading on any/every screen seems heavy-handed for anything coming out of the W3C, even non-normative guidance like what we're working on.

Even in the web context, headings are not required -- but when they are used, they must be descriptive/topical. And that's reasonable to apply in the native mobile app and mobile web context.

JJdeGroot commented 2 months ago

Discussed in today's meeting.

Minutes for 28 August 2024 [Source](https://www.w3.org/2024/08/28-matf-minutes.html#t03) This SC might have cross over with 2.4.4 depending on our definition of links With dynamic loading, do we expect headings to be available on screen when they have not been loaded yet? the actual text seems like it would stay the same to me Mick With mobile, it makes sense that each view has a description at the top of it out of scope for this SC Add best-practice note for headings? I would put that best practice note on Screen Titles, not here julianmka Pushing back: there are many times where headings would be superfluous - they are useful to break up content (e.g. infinite content). Headings should be used to delineate actual content chunks +1 Jamie +1 to julianmka Jamie: shouldn't this SC be in Principle 3 Understandable instead of Principle 2 Operable Jamie This SC doesn't really make sense in operable, since it's not functional.
JJdeGroot commented 2 days ago

Discussed in today’s meeting.

20 November 2024 [Source](https://www.w3.org/2024/11/20-matf-minutes.html#5aa4) ~~~text 2.4.6 Headings and Labels WCAG2ICT seems to interpret 2.4.6 as relating more to content grouping, fwiw Nice thanks Joe_Humbert - I see my last comapny made them custom actions (facepalm) Joe_Humbert this might be higher level - the "nebulous" word for descriptive is normative but does not have a definition Is it a problem that descriptive is not descriptive enough? +1 Joe_Humbert +1 JJ Joe_Humbert 2.4.6 des not talk about context. Labels need to be descriptive, but in links it mentions context Detlev does programmatic text matter over visible text? e.g. and 'X' that has a label julianmka in terms of aligning to WCAG2ICT buttons and labels are things that set context. Wcag2ICT isn't really sufficient at the moment buttons and labels also require context dotjay nothing to add Illai We need to have a place where button names and form labels are made clear Jamie forgot for now JJ, you wanted to Your topic here oooh QuintinB likes this ACTION: Dive deeper into what we would consider a label (button label, link label, etc.) oh, I remember... Label in name should address programmatic text, right Detlev? +1 to Illai ~~~

ACTION: Dive deeper into what we would consider a label (button label, link label, etc.)