W3C

– DRAFT –
(MEETING TITLE)

22 April 2024

Attendees

Present
Bram, Carolina, Devanshu, hdv, Jamers, JJ, julianmka, karla, RacheleDiTullio
Regrets
-
Chair
-
Scribe
hdv

Meeting minutes

Calendly time picker results

[shares screen with results]

JJ: seems like most votes, 15 out of 17, are able to make it into one slot, 15:00-16:00 in my timezone

JJ: (I think that's the time in my timezone)

JJ: leaning towards that time because seems everyone can make it

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

how 2.4.2 relates to mobile

JJ: 2.4.2 is excluded in EN 301 549 and I believe in other places, the reason is that `title` cannot be added in mobile apps

RacheleDiTullio: good example of where screens don't have traditional toolbar/title would be a login screen, so you'd rely on the app's name

JJ: in apps I can see there could be screens that don't need a screen title

JJ: maybe it could be a rule in our guidance but with some exceptions

<JJ> Hidde: app name/title vs screen title, in websites the page title is dynamic and not consistent - thus also important for apps to have screen titles

julianmka: thinking about screens that don't necessarily titles because they are self evident, like login screens… totally agree. But I have experience with screens that don't actually have a name or title and it made navigation really confusing

julianmka: inconsistent nomenclature is a problem

julianmka: so something in guidance should be 'if users can navigate back to a part in the app, there needs to be a reasonable title'

Jamers: can see that name of a page title is what I see in the tab bar to see which pages are in my web browser… but most people don't use the app browser in the same way that we talk about tabs in a web browser

Jamers: so there are different kinds of uses for this SC… using the name of a page in a website is like using the screen in an app… and the other is when I am browser between tabs or apps… that's two different purposes I think

Jamers: and +1 to hdv and julianmka 's points

<julianmka> Also important context for app name -- app switcher

JJ: in the Netherlands I see all banking apps have the same name, all named “Banking”, even if they are from different banks. So the only way to identify which app is from which bank is visually

JJ: eg would be very helpful for some users for apps to have a clearly identifyable name

JJ: rather than just the icon differentiating

JJ: have others seem other types of apps that share the same name?

Jamers: the five banks I worked with all had their own name as the name

JJ: interestingly on iOS it is possible to change the announced name as different from the visual name

julianmka: searching 'clock' or 'alarm clock' in the App Store I see a lot of same names… we could have some guidance but probably be something the marketplace vendor should do something about

JJ: Apple does enforce it in App Store so apps there have unique names, but that doesn't apply to names of what's displayed for downloaded apps

JJ: does anyone know if there is enforcement like that in Play Store?

julianmka: I can see 3-4 apps named Clock in the Play Store right now

Jamers: what's their screenreader names?

julianmka: will need to check

JJ: can see in the App Store they are unique for me

JJ: thanks everyone for great discussion today

JJ: we'll have Target Size for our next meeting

<julianmka> Next week, do we meet on Wednesday?

<JJ> Next week will likely be Wednesday, I will send out notification by this week's Wednesday.

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Succeeded: s/JJ/Devanshu

Succeeded: s/julian/julianmka

Succeeded: s/Topic: how WCAG 2.2 relates to mobile/Topic: how 1.3.1 relates to mobile

Succeeded: s/Topic://

Succeeded: s/2.4.4 this one is excluded in EN 301 549 and I believe in other places, the reason is that `title` cannot be added in mobile apps//

Maybe present: Jamie

All speakers: Devanshu, Jamers, Jamie, JJ, julianmka, Karla, RacheleDiTullio

Active on IRC: Bram, Carolina, Devanshu, hdv, Jamers, JJ, julianmka, karla, RacheleDiTullio