Accessilibity improvements for blind users

Support Developer
1

Hi Alll,

Recently I attended a conference where a blind programer explained his issues when interacting with interfaces and how AI is helping him to be more autonomous. Also he encoraged any programer to review its applications and make them more accessible.

As I’m not an expert a asked AI to review tryton clients codebase and provide a report.
The report is part of this post.

I will like to know if contributions are welcome to improve the clients or if some of the missing features are leaved on purpose to make the codebase simpler.

If contributions are welcome I will try to provide some patches with the help of AI.

Accessibility improvements for blind users

A preliminary source-code review of the Tryton desktop client and Sao (version 8.3.0) identified several areas where accessibility for blind users could be improved.

Both clients already provide useful accessibility foundations, including labelled fields, keyboard shortcuts and standard UI components. The purpose of this review is to identify remaining gaps and suggest practical improvements.

Scope and limitations

This was a source-code review, not a formal accessibility audit or a completed screen-reader usability test. Findings should therefore be treated as implementation issues and verification items, rather than a definitive WCAG compliance assessment.

The review primarily covered the current source files. Sao’s local distribution bundle appeared to differ from the source, and missing local dependencies prevented completing browser-based verification. Actual behaviour should be checked against the deployed version.

Shared issues are listed only once below. Some findings are specific to Sao because HTML/ARIA semantics and GTK accessibility APIs require different implementations.

Improvements affecting both clients

1. Expose required and invalid field states

The shared field-widget implementations primarily communicate required and invalid states through visual styling. The base required-state methods are empty, and equivalent accessible states are not systematically exposed in the reviewed code.

Suggested improvement:

  • In Sao, use native HTML attributes or appropriate ARIA states.
  • In GTK, expose equivalent states through the accessibility API.
  • Associate validation messages with the relevant fields so users can understand and correct errors.

Textual validation messages already exist in parts of both clients, but they do not replace accessible field-level states.

Source references:

  • Sao: sao/src/view/form.js, Sao.View.Form.Widget.display() and set_required().
  • Desktop: tryton/tryton/gui/window/view_form/view/form_gtk/widget.py, Widget.display() and _required_set().

2. Verify complete keyboard access and make shortcuts discoverable

Several relational-field toolbar buttons are excluded from the normal keyboard focus order. Keyboard shortcuts provide alternatives for some actions, particularly in the desktop client.

Excluding a button from the focus order is not necessarily an accessibility failure if an equivalent keyboard interaction exists. However, complete coverage and discoverability need verification.

Suggested improvement: ensure every action is available without a mouse and that users can easily discover the relevant shortcuts or alternative interactions.

Source references:

  • Sao: sao/src/view/form.js, Sao.View.Form.One2Many.
  • Desktop: tryton/tryton/gui/window/view_form/view/form_gtk/one2many.py, toolbar construction and on_keypress().

3. Provide accessible alternatives to charts

The reviewed chart components do not explicitly provide an equivalent accessible data table. The desktop component draws chart content on a Gtk.DrawingArea, while Sao delegates rendering to Billboard and configures click-based actions.

Suggested improvement:

  • Provide an accessible representation of the chart data, such as an equivalent table.
  • Provide keyboard alternatives for chart actions.
  • If an existing list view is intended as the alternative, verify that it is readily accessible and conveys equivalent information.

Source references:

  • Sao: sao/src/view/graph.js.
  • Desktop: tryton/tryton/gui/window/view_form/view/graph_gtk/graph.py.

4. Ensure meaningful names for icon-only controls

Sao contains controls without explicit accessible names, including the mobile navigation toggle. Some desktop buttons rely on images and tooltips without an explicitly assigned accessible name.

The desktop cases require runtime verification: GTK may expose useful information automatically, so the absence of an explicit name in application code does not by itself prove that the button is unnamed.

Suggested improvement: inspect the accessibility tree and ensure every icon-only control has a meaningful name, rather than relying solely on visual icons or hover information.

Source references:

  • Sao: sao/index.html, mobile navigation toggle.
  • Desktop: tryton/tryton/gui/window/view_form/view/form_gtk/binary.py, BinaryMixin.toolbar().

Additional improvements identified in Sao

5. Associate dialogs with their titles

The common dialog implementation creates an element with role="dialog" and a visible title, but does not associate that title with the dialog through aria-labelledby or provide an alternative accessible name.

Suggested improvement: programmatically associate each dialog with its visible title, and provide a meaningful name for dialogs without a visible title.

Source reference: sao/src/sao.js, Sao.Dialog.

6. Label record-selection controls

The select-all checkbox and individual row-selection checkboxes/radio buttons do not have explicit accessible labels in the reviewed implementation.

Suggested improvement: give the select-all control a clear name and make each row-selection control identify the affected record.

Source reference: sao/src/view/tree.js, table construction and row _construct().

7. Make column sorting keyboard-accessible

Sorting is attached to a click handler on the column header, without an equivalent keyboard activation mechanism in the reviewed header implementation. The sorting state is not exposed through aria-sort.

Suggested improvement: provide a keyboard-operable sorting control and expose the current sort direction.

Source reference: sao/src/view/tree.js, sortable-header construction.

8. Complete autocomplete accessibility semantics

Autocomplete provides keyboard interaction and a listbox role, but lacks a complete accessible combobox/listbox implementation.

Suggested improvement: expose the relationship between the input and its suggestions, appropriate option semantics, and expanded/selection state. Verify that screen readers can identify and navigate suggestions reliably.

Source reference: sao/src/common.js, Sao.common.InputCompletion.

9. Expose tree expansion controls and state

Tree expansion controls use images without explicit accessible names and expanded/collapsed states in the reviewed construction code.

Suggested improvement: provide meaningful names, appropriate interactive semantics, keyboard operation and an exposed expanded/collapsed state.

Source reference: sao/src/view/tree.js, tree and row expander construction.

Additional verification needed

The following areas need practical testing before drawing conclusions:

  • Focus placement when opening dialogs and focus restoration when closing them.
  • Screen-reader announcements of dynamic updates, including result counts and record-position changes.
  • Calendar navigation and interaction without a mouse.
  • Accessibility of custom modules, views and complete business workflows.
  • Desktop behaviour on each supported operating system; results on Linux should not be assumed to apply to Windows or macOS.

Suggested acceptance testing

Test complete workflows using:

  • Sao: NVDA with Firefox and Chrome.
  • Desktop client on Linux: Orca.
  • Additional screen-reader/operating-system combinations according to the intended deployment.

Ideally, involve blind users who regularly use screen readers. Cover at least:

  1. Signing in and navigating menus.
  2. Searching, sorting and selecting records.
  3. Creating and editing records.
  4. Managing relational lines and attachments.
  5. Understanding and correcting validation errors.
  6. Completing wizards and interacting with dialogs.
  7. Accessing information otherwise presented through charts or calendars.

Summary

Both clients have useful accessibility foundations, but the identified gaps and unverified interactions mean that reliable, independent use by blind users cannot yet be assumed. Addressing these issues and validating real workflows with screen readers would provide a stronger basis for assessing accessibility.

2

Yes but I stopped reading at this point.