View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007391 | Taler | wallet-core | public | 2022-10-10 19:57 | 2023-01-26 21:53 |
| Reporter | Assigned To | grote | Resolution deadline | ||
| Implementer | Reviewer | ||||
| Release signed by | Deployed by | ||||
| Verifier | Communicator | ||||
| Data protection authority notification required | No | ||||
| CSIRT notification required | No | ||||
| Estimated effort (hours) | Actual effort (hours) | 0 | |||
| Fast-track | No | ||||
| Work package | none | ||||
| Priority | low | Severity | tweak | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.9.1 | Fixed in Version | 0.9.1 | ||
| Summary | 0007391: CS 4.1.2 (LEVEL A) -- Name, Role, Value | ||||
| Description | For 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. | ||||
| Tags | No tags attached. | ||||
| 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 | |
| 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? | |
| 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. | |
| 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. | |
| 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 | |
| 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. | |
| Ok, let's stick to the Android standard for now. I cannot imagine that no 'standard' App can be accessibiity-certified. | |
| Unassigning, as we may get more feedback soon. Once we have that, we can decide what to do next. | |
| Torsten: anything left to do here? Last e-mails exchanged sounded like we can just resolve/no-change-required this one now, right? | |
| 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. | |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-10-10 19:57 | New Issue | ||
| 2022-10-10 19:57 | Status | new => assigned | |
| 2022-10-10 19:57 | Assigned To | => sebasjm | |
| 2022-10-18 23:23 | sebasjm | Note Added: 0019232 | |
| 2022-10-19 20:52 | grote | Note Added: 0019246 | |
| 2022-10-19 20:54 | grote | Note Added: 0019247 | |
| 2022-10-20 09:37 | Christian Grothoff | Note Added: 0019254 | |
| 2022-10-20 09:37 | Christian Grothoff | Priority | normal => urgent |
| 2022-10-20 09:37 | Christian Grothoff | Target Version | git (master) => 0.9 |
| 2022-10-20 15:07 | sebasjm | Assigned To | sebasjm => grote |
| 2022-10-24 11:58 | Christian Grothoff | Note Added: 0019284 | |
| 2022-10-24 17:48 | grote | Note Added: 0019288 | |
| 2022-10-24 18:44 | Christian Grothoff | Note Added: 0019301 | |
| 2022-10-24 18:45 | Christian Grothoff | Assigned To | grote => |
| 2022-10-24 18:45 | Christian Grothoff | Priority | urgent => low |
| 2022-10-24 18:45 | Christian Grothoff | Severity | minor => tweak |
| 2022-10-24 18:45 | Christian Grothoff | Status | assigned => acknowledged |
| 2022-10-24 18:45 | Christian Grothoff | Target Version | 0.9 => |
| 2022-10-24 18:45 | Christian Grothoff | Note Added: 0019302 | |
| 2022-11-06 22:20 | Christian Grothoff | Assigned To | => grote |
| 2022-11-06 22:20 | Christian Grothoff | Status | acknowledged => assigned |
| 2022-11-06 22:20 | Christian Grothoff | Target Version | => 0.9.1 |
| 2022-11-07 18:27 | Christian Grothoff | Note Added: 0019385 | |
| 2022-11-08 14:03 | grote | Status | assigned => informing |
| 2022-11-08 14:03 | grote | Resolution | open => fixed |
| 2022-11-08 14:03 | grote | Note Added: 0019393 | |
| 2022-11-18 21:42 | Christian Grothoff | Fixed in Version | => 0.9.1 |
| 2023-01-26 21:53 | Christian Grothoff | Status | informing => closed |
| 2023-04-13 18:36 | Florian Dold | Category | wallet (TS core) => wallet-core |