Meeting minutes
<JJ> WCAG2Mobile has been published: https://
<JJ> Document: https://
<Jon_Gibbins> Sorry folks, my Internet connection seems too unstable to join today.
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
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
1.3.5 - Identify Input Purpose
<JJ> current agendum?
<JJ> Note: agendum 1.3.1 Info and Relationships is shown above