22 April 2024
[Source](https://www.w3.org/2024/04/22-matf-minutes.html#t02)
## 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.
Discussions:
22 April 2024
[Source](https://www.w3.org/2024/04/22-matf-minutes.html#t02) ## 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 mean1. Applicability of 1.3.1 to Mobile:
2. List Marking and Navigation Bars:
3. Best Practices for Tables:
4. Native Component Considerations: