View Issue Details

IDProjectCategoryView StatusLast Update
0007391Talerwallet (TS core)public2022-11-18 22:42
Reporterttn Assigned Togrote  
PrioritylowSeveritytweakReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Versiongit (master) 
Target Version0.9.1Fixed in Version0.9.1 
Summary0007391: CS 4.1.2 (LEVEL A) -- Name, Role, Value
DescriptionFor all user interface components (including but not limited to: form elements, links
and components generated by scripts), the name and role can be programmatically
determined; states, properties, and values that can be set by the user can be
programmatically set; and notification of changes to these items is available to user
agents, including assistive technologies.

The button that users can use to choose a language has no
defined role nor value (expanded or collapsed). This issue is
present on all pages, for example:
https://demo.taler.net/en/
The buttons in the menu of the app (balances and settings) aren't
announced as buttons by the screenreader software. The same is
true for more buttons, for example, the buttons in the settings
menu.
TagsNo tags attached.

Activities

sebasjm

2022-10-19 01:23

developer   ~0019232

Language button now fixed on demo. I'm not able to find any other button that need the same patch.

Android app still need to be corrected

grote

2022-10-19 22:52

developer   ~0019246

We are using official standard libraries to provide the navigation drawer menu. All menu items are announced properly and the current active one is announced as "checked". I couldn't find a way to make it announce a role "button" as well. Is anybody aware of a way to do this and is this really important? After entering the menu, the user might be aware that the following options are menu items?

grote

2022-10-19 22:54

developer   ~0019247

Something similar applies to the settings. The settings options there are not really buttons. I've had other Android accessibility audits and the lack of announcing settings as buttons wasn't flagged there.

Christian Grothoff

2022-10-20 11:37

manager   ~0019254

I think this may be about specific buttons / widgets within the settings dialog. Anyway, just try to double check what is there, and once you've uploaded a release where you fixed what you could, we'll ask them to look again. Just please try to do it soon.

Christian Grothoff

2022-10-24 13:58

manager   ~0019284

NGI@han.nl writes:

I already got a response from the auditor with a link to a guide. It's in Dutch though, but the code examples are in English.

I’ll try to summarize it here:
 

Every button needs a name, role and value. The website shows examples for Android and ios.

 

Name

On Android, the contentDescription attribute is used for the name of the element: element.contentDescription = "Name"

On iOS, the accessibilityLabel attribute is used for the name of the element: element.accessibilityLabel = "Name"


Role

Android: you can manually set a role using setRoleDescription by AccessibilityNodeInfoCompat. But often it is better to use setClassName to inherit the role of an existing element.

See example on page

iOS: use accessibilityTraits attribute to determine the role. For example, you can set the role “button” with the button trait. Or set the role “link” via the link trait.

 

Value

Android: use setChecked (from AccessibilityNodeInfoCompat) or contentDescription (see example on page)

iOS: use accessibilityValue attribute: element.accessibilityValue = "Value"

If you want to read more, I hope Google Translate can help out ;). See https://appt.nl/kennisbank/richtlijnen/principe-4/richtlijn-4-1/succescriterium-4-1-2

grote

2022-10-24 19:48

developer   ~0019288

Thanks. That's helpful. Although I find it weird that they suggest hacking Android's provided accessibility framework to that degree, I tried this. It doesn't really work for preferences as suggested. Android's own documentation says:

> Preferences aren't views. They should not need any accessibility changes, unless the view hierarchy is customized.

We don't customize the view hierarchy though, but use normal preferences. Also, when going through settings with a screenreader, the settings that can be clicked and lead to further screens read "Double tap to activate" at the end which should make it clear that they work like buttons. Seems odd to me to require further hacks for it to say: "Button. Exchanges. Manage list of exchanges known to this wallet"

The same is true for the menu items "Balances" and "Settings". It would take major hacky surgery to make a screenreader read "Button. Balances" instead "Balances. Double tap to activate".

The way I understand this, is that it should be important for a user using accessibility services to understand which screen element the screen reader is announcing can be interacted with and which ones not. Even though "Double tap to activate" is arguably not as nice as "Button", it *is* the standard on Android and all apps behave like this.

Christian Grothoff

2022-10-24 20:44

manager   ~0019301

Ok, let's stick to the Android standard for now. I cannot imagine that no 'standard' App can be accessibiity-certified.

Christian Grothoff

2022-10-24 20:45

manager   ~0019302

Unassigning, as we may get more feedback soon. Once we have that, we can decide what to do next.

Christian Grothoff

2022-11-07 19:27

manager   ~0019385

Torsten: anything left to do here? Last e-mails exchanged sounded like we can just resolve/no-change-required this one now, right?

grote

2022-11-08 15:03

developer   ~0019393

Yes, I was happy to hear that they agreed with me and don't think a "strict" reading of this requirement is needed here for Android.

Issue History

Date Modified Username Field Change
2022-10-10 21:57 ttn New Issue
2022-10-10 21:57 ttn Status new => assigned
2022-10-10 21:57 ttn Assigned To => sebasjm
2022-10-19 01:23 sebasjm Note Added: 0019232
2022-10-19 22:52 grote Note Added: 0019246
2022-10-19 22:54 grote Note Added: 0019247
2022-10-20 11:37 Christian Grothoff Note Added: 0019254
2022-10-20 11:37 Christian Grothoff Priority normal => urgent
2022-10-20 11:37 Christian Grothoff Target Version git (master) => 0.9
2022-10-20 17:07 sebasjm Assigned To sebasjm => grote
2022-10-24 13:58 Christian Grothoff Note Added: 0019284
2022-10-24 19:48 grote Note Added: 0019288
2022-10-24 20:44 Christian Grothoff Note Added: 0019301
2022-10-24 20:45 Christian Grothoff Assigned To grote =>
2022-10-24 20:45 Christian Grothoff Priority urgent => low
2022-10-24 20:45 Christian Grothoff Severity minor => tweak
2022-10-24 20:45 Christian Grothoff Status assigned => acknowledged
2022-10-24 20:45 Christian Grothoff Target Version 0.9 =>
2022-10-24 20:45 Christian Grothoff Note Added: 0019302
2022-11-06 23:20 Christian Grothoff Assigned To => grote
2022-11-06 23:20 Christian Grothoff Status acknowledged => assigned
2022-11-06 23:20 Christian Grothoff Target Version => 0.9.1
2022-11-07 19:27 Christian Grothoff Note Added: 0019385
2022-11-08 15:03 grote Status assigned => resolved
2022-11-08 15:03 grote Resolution open => fixed
2022-11-08 15:03 grote Note Added: 0019393
2022-11-18 22:42 Christian Grothoff Fixed in Version => 0.9.1