briar issueshttps://code.briarproject.org/groups/briar/-/issues2020-11-15T20:10:45Zhttps://code.briarproject.org/briar/briar/-/issues/1401Make transport indicators usable by colourblind users2020-11-15T20:10:45ZakwizgranMake transport indicators usable by colourblind usersUser feedback: "For productivity purposes I use my phone in greyscale mode, it's at the same time a simulation of color blindness. I've noticed that it's hard to distinguish the internet/WiFi/Bluetooth indicators' active green from the i...User feedback: "For productivity purposes I use my phone in greyscale mode, it's at the same time a simulation of color blindness. I've noticed that it's hard to distinguish the internet/WiFi/Bluetooth indicators' active green from the inactive grey. The solution could be putting a dot/underscore to indicate WiFi is enabled."https://code.briarproject.org/briar/briar/-/issues/1518Touch target for screen filter checkbox is too small2020-11-15T19:10:24ZakwizgranTouch target for screen filter checkbox is too smallGoogle Play's pre-launch report warns that the screen filter checkbox should be at least 48dp high for accessibility. The current size varies from 32 to 36dp depending on the device.
The same may be true of other checkboxes, but the aut...Google Play's pre-launch report warns that the screen filter checkbox should be at least 48dp high for accessibility. The current size varies from 32 to 36dp depending on the device.
The same may be true of other checkboxes, but the automated testing doesn't go past the setup screen yet (I'm working on a script to allow it to do so).https://code.briarproject.org/briar/briar/-/issues/1519Password entry and confirmation fields should have descriptions2020-11-15T19:09:36ZakwizgranPassword entry and confirmation fields should have descriptionsGoogle Play's pre-launch report warns that the password entry and confirmation fields should have descriptions for screen reader accessibility.
https://support.google.com/accessibility/android/answer/7158690
This may apply to other fie...Google Play's pre-launch report warns that the password entry and confirmation fields should have descriptions for screen reader accessibility.
https://support.google.com/accessibility/android/answer/7158690
This may apply to other fields in the app, but the automated tests don't yet get past the setup screen.https://code.briarproject.org/briar/briar/-/issues/1749Blog post dividers are hard to see2020-11-15T15:32:03ZakwizgranBlog post dividers are hard to seeA user reported that the dividers between sections of a reblogged/commented post are hard to see (there isn't enough contrast between the grey divider and the white background).A user reported that the dividers between sections of a reblogged/commented post are hard to see (there isn't enough contrast between the grey divider and the white background).https://code.briarproject.org/briar/briar/-/issues/1786Some buttons lack name/role/value for accessibility2020-11-15T13:52:36ZakwizgranSome buttons lack name/role/value for accessibilityThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) found several examples of buttons that weren't marked with an appropriate name, role and value to enable screen readers to handle them ...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) found several examples of buttons that weren't marked with an appropriate name, role and value to enable screen readers to handle them properly:
- [ ] The `(i)` button for showing information lacks a role (should be "button")
- [ ] The `+` button for adding contacts lacks a name
- [ ] The speed dial buttons for adding contacts lack a role for the text and a name for the icon
- [ ] The buttons in the navigation menu lack a role
- [ ] The transport indicators lack a value
- [ ] In the private group list and possibly elsewhere, the action bar's overflow menu button and the menu items lack roles
- [ ] The button for opening/closing the emoji keyboard lacks a name
- [ ] The "Reply" button (in forums and private groups?) lacks a role
- [ ] When the buttons for scrolling up/down to the previous/next unread message are hidden, they're still visible to screen readers but don't work, and don't have a name, role or value
- [ ] The reblog button has the name "Add a comment" rather than "Reblog"
If any of these are tricky to handle we can create subtasks.https://code.briarproject.org/briar/briar/-/issues/1787Transport indicators are not accessible to colourblind people2020-11-15T13:51:37ZakwizgranTransport indicators are not accessible to colourblind peopleThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the transport indicators in the nav drawer rely on colour alone to indicate their state. A second visual cue should be pr...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the transport indicators in the nav drawer rely on colour alone to indicate their state. A second visual cue should be provided for colourblind users.https://code.briarproject.org/briar/briar/-/issues/1788Text fields should have labels2020-11-15T13:51:14ZakwizgranText fields should have labelsThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the way we style text fields, showing placeholder text but not a label, is an accessibility issue because the placeholder...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the way we style text fields, showing placeholder text but not a label, is an accessibility issue because the placeholder text disappears when the user starts to type, leaving no indication of the field's purpose.
This is my fault - I argued for removing the labels because I think the way they move and change size when the field gains or loses focus interacts badly with automatically giving focus to the first text field.https://code.briarproject.org/briar/briar/-/issues/1789Changes to status messages aren't visible to screen readers2020-11-15T13:49:20ZakwizgranChanges to status messages aren't visible to screen readersThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that when status messages such as those shown in the pending contact list ("Connecting", etc) are updated, screen readers aren...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that when status messages such as those shown in the pending contact list ("Connecting", etc) are updated, screen readers aren't automatically aware that the text has changed.
One way to make screen readers aware that text has changed is to give focus to the changed element. The "Password is too weak" message on the setup screen is an example of a status message that's correctly handled by screen readers.https://code.briarproject.org/briar/briar/-/issues/1790Check whether text has enough contrast for accessibility2020-11-15T13:48:54ZakwizgranCheck whether text has enough contrast for accessibilityThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the placeholder text in input fields appears to have low contrast, but this couldn't be verified as the app doesn't allow...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the placeholder text in input fields appears to have low contrast, but this couldn't be verified as the app doesn't allow screenshots. There may be other places in the app, such as the coloured status messages in the pending contact list, where we're not meeting accessibility guidelines for contrast.
Contrast should be at least 4.5:1 for "normal" text or 3.0:1 for "large" text, defined as 18px or 14 px + bold. The light and dark themes need to be checked.https://code.briarproject.org/briar/briar/-/issues/1791Non-text content should have a textual alternative2020-11-15T13:48:30ZakwizgranNon-text content should have a textual alternativeThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) found several places in the app where non-text content lacks a textual alternative:
- [ ] Password strength indicator
- [ ] Checkmarks...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) found several places in the app where non-text content lacks a textual alternative:
- [ ] Password strength indicator
- [ ] Checkmarks in the power management setup screen
- [ ] Checkmarks in the stepper when adding a contact remotely
- [ ] Diagram explaining how QR codes should or should not be exchanged
If any of these involve a lot of work we can create subtasks.https://code.briarproject.org/briar/briar/-/issues/1792Stepper isn't read in a meaningful order by screen readers2020-11-15T13:47:05ZakwizgranStepper isn't read in a meaningful order by screen readersThe [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the "stepper" that shows the steps in the process of adding a contact remotely isn't read in a meaningful order by screen...The [Accessibility Foundation audit](https://briarproject.org/raw/Accessibility_Report_NGI_Briar.pdf) reported that the "stepper" that shows the steps in the process of adding a contact remotely isn't read in a meaningful order by screen readers. TalkBack navigation reads the steps "1 - Exchange links, 2 - Choose nickname" as "1, 2, Exchange links, Choose nickname".https://code.briarproject.org/briar/briar-gtk/-/issues/97Accessibility User Testing2021-02-08T12:12:33ZNicoAccessibility User TestingWe should test whether Briar GTK is accessible to users with [different types of disability](https://developer.gnome.org/accessibility-devel-guide/stable/idm140487279365936.html.en) by using tools like [Orca](https://wiki.gnome.org/Proje...We should test whether Briar GTK is accessible to users with [different types of disability](https://developer.gnome.org/accessibility-devel-guide/stable/idm140487279365936.html.en) by using tools like [Orca](https://wiki.gnome.org/Projects/Orca).
Relevant links:
* [GNOME Accessibility Developers Guid](https://developer.gnome.org/accessibility-devel-guide/stable/index.html.en)
* [Accessibility in GTK 4](https://blog.gtk.org/2020/10/21/accessibility-in-gtk-4/)GTK 0.2.0-beta1https://code.briarproject.org/briar/briar/-/issues/2058Disabled settings are difficult to read2021-06-08T12:56:08ZakwizgranDisabled settings are difficult to read* Briar version: 1.3.4
* User feedback: "The greyed out options in the settings are a bit to difficult to read (for me).
A bit more contrast could still signal it's greyed out, but offer better readability."* Briar version: 1.3.4
* User feedback: "The greyed out options in the settings are a bit to difficult to read (for me).
A bit more contrast could still signal it's greyed out, but offer better readability."https://code.briarproject.org/briar/briar-desktop/-/issues/84Accessibility for Visually Impaired2023-01-09T21:29:49ZpaulAccessibility for Visually Impaired"The 2018 National Health Interview Survey (NHIS) data release established that an estimated 32.2 million adult Americans (or about 13% of all adult Americans) reported they either "have trouble" seeing, even when wearing glasses or cont..."The 2018 National Health Interview Survey (NHIS) data release established that an estimated 32.2 million adult Americans (or about 13% of all adult Americans) reported they either "have trouble" seeing, even when wearing glasses or contact lenses, or that they are blind or unable to see at all." ([source](https://www.afb.org/research-and-initiatives/statistics))
This issue looks to investigate ways we can optimize Briar Desktop to improve accessibility for the visually impaired.
Some initial investigation:
- Our color selection.
- Jetpack Compose tools to help screen readers parse Briar Desktop.
- Jetpack Compose tools to help navigate the UI with keyboard only.Desktop 1.0.0https://code.briarproject.org/briar/briar-desktop/-/issues/341Briar Desktop Accessibility Audit (Ubuntu+Mac)2023-01-09T21:39:55ZElio Qoshielio@ura.designBriar Desktop Accessibility Audit (Ubuntu+Mac)The accessibility audit supported by OTF has been completed, following is a detailed spreadsheet report with screenshots and recommendations on how to address over 70 accessibility issues. The accessibility audit has been conducted with ...The accessibility audit supported by OTF has been completed, following is a detailed spreadsheet report with screenshots and recommendations on how to address over 70 accessibility issues. The accessibility audit has been conducted with keyboard as well as screen readers (Voice Over on macOS and Orca on Ubuntu).
https://docs.google.com/spreadsheets/d/17G_qYlHzXJJwyc7d2y6vXC-qyDA2ia-dqbBpuQXnteE/edit?usp=sharing
Each issue includes various details for triaging and provided required context:
- Issue Number
- Environment (Operating System details)
- Page Name (which screen of the application this issue appears in)
- Issues/Summary (issue description)
- Actual Result (the behavior of the issue)
- Expected Result (how the experience should behave ideally)
- User Impact (the repercussions of the issue)
- Screen Images (annotated screenshot)
- Recommendation (how to solve this issue)
- WCAG Guideline (link on the WCAG chapter the issue violates)
- Severity ( how severe this issue is)
[Briar_Desktop_Accessibility_Report.ods](/uploads/5360e4fc7f43fe4336d1e29345e2d628/Briar_Desktop_Accessibility_Report.ods)[Screenshots.zip](/uploads/b180dda7e0374769cb8936cca798c546/Screenshots.zip)Desktop 1.0.0SebastianSebastianhttps://code.briarproject.org/briar/briar-desktop/-/issues/343Improve color contrast2022-09-27T08:10:08ZMikolai GütschowImprove color contrastDuring the accessibility audit #341 several issues were identified concerning poor color contrast:
- [x] registration screen: text field label (light blue on white/black background) > !213
- [x] settings/change password screen: text fi...During the accessibility audit #341 several issues were identified concerning poor color contrast:
- [x] registration screen: text field label (light blue on white/black background) > !213
- [x] settings/change password screen: text field labels (light blue on white) > !213
- [x] settings screen: "change password" button (light blue on white/black) > !213
- [x] registration screen: "next" button (black text color on blue/gray (disabled) button) > already fixed on current `main`
- [ ] registration screen: visual focus indicator on "show/hide password" button (light gray on white)
- [x] registration screen: password strength indicator (light green on white / dark red on black) > !211
- [x] registration screen: form error color (red on black) > !202
- [x] message compose screen: send button (light green on white) > !212
these two issues were post-poned to #364:
- registration screen: disabled "next" button if some of the fields are not properly filled (light gray on white/black)
- settings/change password screen: disabled button (light gray on white)
as well as:
- add contact screen: close button (system-dependant window decoration, so I don't think we can/should do anything about it)Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-mailbox/-/issues/129Accessibility optimizations2023-08-28T16:00:12ZSebastianAccessibility optimizationsWe could check that accessibility is working nicely within the app, i.e. screenreaders can give visually impaired users a nice overview across the different workflows and fragments.We could check that accessibility is working nicely within the app, i.e. screenreaders can give visually impaired users a nice overview across the different workflows and fragments.https://code.briarproject.org/briar/briar-desktop/-/issues/364Revise usage of disabled buttons2022-09-27T08:10:08ZMikolai GütschowRevise usage of disabled buttonsas a follow-up of https://code.briarproject.org/briar/briar-desktop/-/issues/343#note_67101
TD;LR: We should reconsider if we really need disabled buttons as they are bad practice UX-wise and especially for accessibility.as a follow-up of https://code.briarproject.org/briar/briar-desktop/-/issues/343#note_67101
TD;LR: We should reconsider if we really need disabled buttons as they are bad practice UX-wise and especially for accessibility.https://code.briarproject.org/briar/briar-desktop/-/issues/366Improve screen-reader support2023-04-17T22:04:24ZMikolai GütschowImprove screen-reader supportTargeting issues raised in #341 and as part of #84.
- Heading structure: > not supported by upstream Compose (https://github.com/JetBrains/compose-jb/issues/2119)
- [ ] "Welcome to Briar" on login and main screen (no chats)
- [ ] co...Targeting issues raised in #341 and as part of #84.
- Heading structure: > not supported by upstream Compose (https://github.com/JetBrains/compose-jb/issues/2119)
- [ ] "Welcome to Briar" on login and main screen (no chats)
- [ ] contact name in chat screen
- [ ] "Settings" on SettingsScreen
- Image(Button) contentDescription:
- [ ] Briar logo on login > only of decorative nature, automatically skipped over by VoiceOver
- [x] back and info button on login > !223 and info button already "About Briar Desktop" on `main`
- [x] menu button in chat screen > already "Show Contact Menu" on `main`
- [x] add contact button without chats > fixed on `main`
- [x] attachment button in chat screen > fixed on `main`
- Missing context:
- [x] show password buttons on login/change password > automatically grouped on macOS/VoiceOver
- [x] labels for text fields (registration screen) > !225
- Missing list grouping:
- [x] contact list > !218
- [x] settings as list > !224
- Missing state information (expanded/collapsed): Dropdowns/Pop-Ups not supported by Compose https://github.com/JetBrains/compose-jb/issues/2185
- [ ] menu button in chat screen
- [ ] theme/language settings, also dynamic changes
- Misc:
- [ ] error message on login (not read out loud) > upstream bug: https://github.com/JetBrains/compose-jb/issues/2277
- [x] about dialog (no exit button, table not marked as such, email is not link) > !221
- [x] message count/online status in contact list > !218
- [x] "keyboard trap" in compose message text field (tab button is stuck in text field) > !222
- [ ] Missing landmarks on MainScreen to convey structure to screen-reader user > not supported by Compose
- [x] Keyboard focus does not go to close button on add contact dialog > probably missing OS-functionality on Ubuntu/Orca which is anyhow not supported, confirmed to work on macOS with VoiceOver as expected
- [ ] Dropdown not marked as such (settings) > Dropdowns/Pop-Ups not supported by Compose https://github.com/JetBrains/compose-jb/issues/2185
- [x] Briar link name/label on Add Contact dialog > !230
- [x] Add attachment button not keyboard-focusable on macOS > !222Mikolai GütschowMikolai Gütschowhttps://code.briarproject.org/briar/briar-mailbox/-/issues/147Research accessibility testing2023-08-28T16:00:09ZakwizgranResearch accessibility testingFind out what would be involved in testing the Mailbox app for accessibility, and what resources are available to help with this testing.Find out what would be involved in testing the Mailbox app for accessibility, and what resources are available to help with this testing.