Success Criterion 1.3.1 - Info and Relationships - Level A

[JJdeGroot]

Discussions:

22 April 2024

Source

how 1.3.1 relates to mobile

JJ: there's a comment from Karla on 1.3.1 where she says not sure if she agrees it applies

JJ: [shares Understanding doc for 1.3.1]

JJ: the goal is “Information about content structure is available to more people.”, examples are mostly about forms

JJ: I would say 1.3.1 applies to apps, just differently… do people have examples of differences?

julianmka: was thinking about things like radios that are semantic in Android

Karla: seems like we should find examples for that

JJ: is there maybe something you are doing that applies?

Karla: headings is an example that we can do better on mobile

JJ: would conclude it does apply but different things to focus on

JJ: another thing… do we need to mark the index and start/end of list for lists?

JJ: Joe says in a comment that for lists on Android, set position and set size or accessibilityDelegate

JJ: to me apps would usually have one heading level, multiple probably rare

julianmka: we probably want to make sure there is nuance in the guidance we provide as people seem to want to apply practices of web directly to mobile

JJ: how do we think about the navigation bar on Android?

JJ: I believe in Android it is not marked as a heading but it is possible to subclass the toolbar and make it a heading… but on iOS I believe it is marked as heading? how do we feel about this when auditing an app?

Devanshu: I think it should be marked screen title

JJ: so HTML equivalent of a page title?

Devanshu: yes

Devanshu: for Android we can set the screen title from the APIs in the activities

Devanshu: as soon as AT user goes from one screen to another, the first thing that is announced is the screen title

JJ: so this is a way for users to know the first element they hear is the screen title

RacheleDiTullio: yes good to have that but semantically should still be a heading

JJ: should focus start at the back button or start at the title?

Jamie: consistency would be helpful to provide, so if it's going to be the back button, always the back button

JJ: agreed that is important…and may be confusing if people switch between apps that it is inconsistent

Jamie: would be good to talk to folks in Apple and Google about where these relationships are intended to be natively

Jamie: “go native” would be consistent too with WCAG

JJ: yes would be good to get them involved in some of these best practices

julianmka: we've also seen them change over time what the best practices look like

JJ: how do we think about marking headings of tables? does anyone know what's the best practice for building accessible tables in Android and iOS?

Devanshu: specifically at @@@ we use indexing

Devanshu: @@@2 should only be used when it increases accessibility

JJ: with Android it is quite customisable how an app is perceived by users of assistive technologies

JJ: what did you mean re responsiveness?

Devanshu: if accessibilitydelegate helps in making the screen more responsive, I'd advice refrain from using it

JJ: there was also a comment from Julian about Paul J Adams's Swift UI table techniques

JJ: will be worth checking out native components and first party stuff

karla: re tables in iOS… for the description of products, we use them, but we don't use index of row for information in the cell

julianmka: there is difference in meaning between tables in iOS and say, Web… so might be worth disambiguating what we mean

1. Applicability of 1.3.1 to Mobile:

• JJ: Shared Karla's comment questioning the application of 1.3.1 to mobile and emphasized the importance of understanding its relevance in the mobile context.
• julianmka: Suggested exploring differences in the implementation of semantic elements like radios on Android compared to web environments.
• Karla: Identified headings as an area where mobile accessibility can be improved.

2. List Marking and Navigation Bars:

• JJ: Raised questions regarding the marking of lists and navigation bars on mobile platforms, highlighting potential differences between Android and iOS.
• Devanshu: Shared insights into marking screen titles in Android activities and the importance of consistent navigation behavior.

3. Best Practices for Tables:

• JJ: Inquired about best practices for marking headings in tables on Android and iOS platforms.
• Devanshu & Karla: Shared practices from their experiences, emphasizing the differences between iOS and web table semantics.

4. Native Component Considerations:

• JJ: Proposed exploring native components and first-party techniques for building accessible tables, citing Paul J Adams's Swift UI table techniques.
• Karla: Highlighted differences in the meaning and usage of tables between iOS and web environments.

[JJdeGroot]

How do we deal with Images that are not marked up with the role image?

• Headers not marked as heading fail under 1.3.1 because conveys structure.
• Would an image not marked as image also fail under 1.3.1? Would the structure be unclear if you wouldn't know the label that's being read is actually alt-text for an image, and not a text element?

See also: #48 (comment)

[detlevhfischer]

Are there best practices / recommendations regarding the programmatic avalability of important text-level semantics? I think of the strikethrough style that we often find in ecommerce context (old price is market with strikethrough).

[JJdeGroot]

Discussed in today’s meeting.

22 January 2025

Source

Summarized previous discussion and ideas for guidance captured in the Github issue (#1)

<JJ> [w3c/matf#1](https://github.com/w3c/matf/issues/1)

Illai: On web there is standardization for custom elements and how their constituent parts work together. On mobile, we have multiple platforms/frameworks that implement these relationships differently. How do we convey guidance on this at a high level?

JJ: Reviewing original SC language and definitions. Emphasis that this SC is part of the perceivable principle.

Joe_Humbert: I agree with Illai that it would be great to have such guidance but I'm not sure if it's possible. The web standards are at least somewhat open, whereas iOS and Android are more closed.

Illai: How would we test? Different platforms or frameworks will produce different output from assistive technology.
… there might be a barrier in testing for this SC.

<Joe_Humbert> Illai I think we might be able to address your concerns (in the future) with techniques documents that include how to test on iOS/Android/React/others

<JJ> How do we deal with paragraph navigation?

JJ: How much should developers code to mirror the visual layout? E.g. multiple paragraph elements
… The difficulty in this SC is how to test and how to fix it.

JJ: What other kind of definitions might we need to help clarify this SC? Add a note about information, structure, relationships?

<JJ> julianmka: in mobile apps, you can usually overcome 1.3.1 by following mobile best practices

<Jon_Gibbins> I feel those terms (information, structure, relationships) may be a little too generic to pin down here in definitions of key terms. It’s something we may need to address on an SC by SC basis?

<Jamie> +1 @Julian

<Jamie> +1 julianmka

<Joe_Humbert> +1

ACTION: Add note about following mobile best practices (and write down what these would be)

julianmka: A lot of pain in testing 1.3.1 can be mitigated by following good mobile design practices. It's much harder to build apps accessibly when you're shoving web conventions into a mobile app context.

• ACTION: Add note about following mobile best practices (and write down what these would be)
• ACTION: Review how key terms Information, structure, and relationships apply in mobile context

[jamieherrera]

One of my goals in this Task Force is to provide people with clarity (generally, but it seems to always come back to 1.3.1 and 4.1.2) about whether the expectation for native app accessibility is that authors are responsible to add a11y information about a relationship, such as with a custom string, where it's not provided out of the box in native code? Or let the limitations of the technology guide whether it's a WCAG conformance failure? Does this change when creating custom components or hybrid content?

On my mind today is the use of earcons or other haptic or hint feedback when a SR user moves into or out of a particular type of component. Some components natively have that feature and others do not.

[JJdeGroot]

Discussed in today’s meeting. Will continue next week.

30 April 2025

Source

pauljadam ARIA landmarks exist on web, but can't do this on mobile. Apple never tells you what to do with it. How do we write success and failure techniques

[JJdeGroot]

Discussed in today’s meeting.

7 May 2025

Source

JJ discussing the current language and previous discussions and comments about this SC from github an previous meetings

<pauljadam> iOS has heading levels but not Android (yet)

<Aash> +1 to Illai

<rachaely> +1 to Paul

<Jamie> +1 pauljadam

Illai brings up the topic of heading levels and the issues were some OSes do not support heading levels. How do we hand this

JJ suggested an action to develop a note about heading levels and the associated research

ACTION: Add Note about heading levels as part of 1.3.1

Jamie asked if relationships need to be conveyed programmatic give the current capabilities of the OSes and AT

<Illai> +1 Jamie

<JJ> Tables? Table headings?

rachaely in regards to Jamie comment about possibly shimmying it it., It may be possible to do this for headings by adding it to the accessible name

Jamie said the she meant more relationships than just headings

rachaely asked for examples of what Jamie meant

<JJ> indicating modals?

<JJ> marking containers

Jamie gave the example of inline dialogs and also the ser experience when large chnks of content are added or removed. Are accessible names adjustments needed to communicate this information.

JJ gave descriptions of different types of relationship and structure that may need to be commnicated

Jamie asked if missing information would be a best practice vs failre

<JJ> JJ: Examples would be tables, table headers, table rows, table columns, marking containers, indicating modals, etc. that exist on mobile but are more difficult to mark up in the accessibility tree

Detlev discussed how many of these requirements were created based on content heavy webpages as opposed to mobile where their may be significantly less content in a "view"

<rachaely> +1 to Detlev

<julianmka> +1 to Detlev

Detlev would this semantic information be helpful to the user

Illai has concerns about the relationship part of the SC in relation to custom/composite elements. The mobile OSes lack some of the attributes to communicate this information or the generally accepted techniques. Mentions different ARIA attributes like aria-controls

<Illai> BTW I am not saying not fail for it' we should probably not allow it at all

<pauljadam> on iOS you have .accessibilityLabel which works the same as aria-label, you can copy how aria-labelledby works using a variable to hold the string you want to set as the label, that's how you would make a <label> too but it does not set focus to the input when you tap it

JJ says definitions in our Note and possibly mapping attributes from different platforms., Acknowledging that people on the call are leaning to be lenient and not failing. This requires people to state up to date on OS support

<Detlev> +1 for not making exceptions for dev platforms that don't support semantics available in native development

<JJ> [Android 16 will get native expand/collapse states + labelled by multiple elements](https://developer.android.com/about/versions/16/features#a11y-apis)

Tanya is worried about requests for exceptions. End users do not care about native IOS/Android or cross-platform frameworks. We need to this about how we treat different platforms. Contextual context for users can help. Tanya gave examples of banking apps and example of rejections/failures for things like missing table semantics

<Zakim> rachaely, you wanted to in my opinion, we can't fail something that developers don't have a way to implement natively. my recommendation would be a best practice for that scenario

JJ we need to look at where interactions might not pass and platform capabilities

<pauljadam> most a11y user research studies are not published

rachaely back to Jamie comments. We should not fail if developer cannot add the required attributes. Has there been user research that could help inform this discussion?

<Zakim> JJ, you wanted to add that we might need to add a list of capabilities on Android/iOS in regards to marking up information and relationships in a note?

<pauljadam> I've created prototypes for headings user research on iOS and the users preferred headings which is not surprising and they were fine with heading levels.

<rachaely> +1 to maintaining capabilities list

JJ Not aware of research. 1.3.,1 is beneficial to screen reader users but it is also about Perceivable and visual information. Worried about our guidance if this change. Most OSes only get major updates once a year

<pauljadam> I would keep these guidelines more generic so that you don't have to list out every a11y API that is supported and not supported and then update that over time as the OS' improve.

Jamie good way to think about this is "What is the current state". Feels there will need to be multiple notes and compromises in this group. points out that the SC mentions "programmatic or are available in text"

<Zakim> JJ, you wanted to mention how to deal with native elements that might not pass 1.3.1 requirements, but could be enhanced with a11y API's

Jamie concerned that if it is not native available are we (and users) missing out

<pauljadam> A visual user probably does not even know how many rows are on a scrolling list of rows, not sure a screen reader user needs to know how many either.

JJ discussing how we deal with non-conformance of native elements. Gives examples of android set size and index versus iOS were that information is less common. Is it reasonable to require developers to add what is not available natively

JJ also where platform has support, but not individual elements

<pauljadam> They would be able to do 3 finger scroll to move page by page, not required to swipe element by element

julianmka native information not supported, but useful to users may be a good place for best practices. Describing non-visual user vs sighted user navigating row-based content on mobile

<rachaely> +1 to hints, i was thinking of this earlier, but forgot to mention it

<julianmka> Agreed on hints

<pauljadam> WCAG would not expect a developer to add "2 of 6" type index announcements to a11y Hints.

<rachaely> pauljadam i'd recommends hints as a best practice

<pauljadam> That would be like expecting and android developer to hack on a "Heading Level 2" hint

JJ acknowledges that these are good ideas but worries about both empowering users, but also avoiding overload., Mentions the use of hints. Talks about order of attributes and how this impacts users or goes against user preferences

<pauljadam> If you want a heading to speak its level or a list of rows to speak index numbers you need to file bug reports with Apple and Google and they would have to make that happen.

Jamie Strong opinions about the "available in text" part of the SC?

The more programmatic the better to support user choice and preference

<Zakim> JJ, you wanted to emphasize its mostly important for people coming from web to understand the limitations and possibilities for mobile apps

<Jamie> "possible" with customizations... or "expected" from native components?

ACTION: Figure out what the capabilities and limitations of Android and iOS are related to 1.3.1

<Detlev> Joe_Humbert: Need to get agreement on minimum requirements - heading levels, tables, descriptions?

<Jamie> +1 Joe_Humbert

ACTION: Do we need an exception for native elements / native patterns?

<Detlev> ...how do push Apple etc. to add semanticas that are currently missing?

<pauljadam> Apple would tell you to file a Feedback Assistant Bug Report where it goes to disappear into the void

<Jamie> +1 and +1

<Detlev> ...now Android has native expand/collaps

thank Detlev

<pauljadam> If you're asking my opinion I would remove the "or are available in text" part :)

the group may need to come to a consensus on what minimum attributes and properties are needed for conformance. If some of these are missing how do we get companies (Google/Apple) to add the missing attributes and properties so that can be implemented by developers

<JJ> Poll: Apply 1.3.1 directly as written, only adding notes?

<Jamie> 0

Jamie How do we feel about the current text of the SC? Do we need to make changes or is in good as is

<rachaely> +1

<julianmka> +1

<Tim> +1

<Tanya> +1

<Aash> +1 (with notes)

<Jamie> 0

<Illai> -1

<Carol> +1

<Joe_Humbert> +1 for as written agree with Jamie about need for notes

<pauljadam> "or are available in text" seems too vague and confusing on how to apply, or it seems like it's more for plain-text note pad type documents and not web content.

<Detlev> 0 removing "available in text" could make sense but would deviate from WCAG - and may nit do much harm?

<Carol> agree with Jaime about the notes

<julianmka> also on board with notes

<pauljadam> I'm not sure if we're actually allowed to remove things :)

<Jamie> pauljadam the point of the MATF is to provide guidance on accepting "as written" or vary from the SC

Illai feels that this SC is to vague and general (even for web). Taking it as is may not help users in the way this SC was intended

JJ acknowledges we can modify SC is small ways, but notes can help do more

<Detlev> would adding a heading level as hint count as "are available in text"?

<pauljadam> Does the text have to be visible text?

Jamie The wording may be limiting the groups thinking/work. Acknowledges that there is a lot of variance from company to company on what passes fails this SC for both mobile and web

addressing pauljadam because this is in Precievable I would say Yes it needs to be visible to provide access to more users

Jamie is worried about being to specific versus too general

<pauljadam> I figured that "text" means text everyone can see

<Zakim> Detlev, you wanted to respond to 0 vote and to

JJ thinks we need to do something to help developers meet this SC

<Jamie> Joe_Humbert not worried per se, more that we need to be more explicit in our. version and possibly define / redefine the definitions

<pauljadam> A simple table could be grouped as one single focused element then you would not need to hack on the row and column header announcements.

Detlev describing why he gave a 0. He is not sure what is better to be to more detailed or more general. Really need to consider how are guidance is helping users

JJ will add more actions if some were missed. share out the draft publicxation

Poll outcome: mostly in favor of applying 1.3.1 directly as written, with the addition of notes. Consider removing "or are available in text."

• ACTION: Add Note about heading levels as part of 1.3.1
• ACTION: Figure out what the capabilities and limitations of Android and iOS are related to 1.3.1
• ACTION: Do we need an exception for native elements / native patterns?
• ACTION: Determine minimum requirements for conformance (heading levels, tables, rows, columns, etc.)
• ACTION: Research ways to encourage platform providers (Apple/Google) to add missing semantic attributes
• ACTION: Investigate user research on the impact of semantic information in mobile contexts
• ACTION: Clarify the interpretation of "or are available in text" in the SC for mobile contexts