Re: [orca-list] Let's celebrate! Red hat has hired a blind person to improve accessibility!



Hi Lukáš,

First, I congratulate for you the new job in Red6, and I wish you successful results in Red6 for your accessibility improvements. Even the two of us have similar careers, the only difference being that I don't have a degree in software engineering, I'm just a programmer, and i don't have a university degree. :-):-) I’m completely visually impaired, I don’t see any light at all, but I’ve been using the computer since I was ten, I’ve been using Linux since 1999 (usual Debian based distributions primary level). :-) :-) I am gratifying for the result you have achieved, I wish you to be at Red6 for a long time and achieve as many successful results as possible and find happiness in your work, similar with me in IT Foundation for the Visually Impaired - Hungary, where I have been working for twenty-two years in Hungary.

I am a screen reader user too (similar with other Orca-list users), I not using Fedora (using Debian my primary job), but experienced similar results.

A technique suggestion with possible easyest future your work with automatic testing related, or ci/cd integration if tool is not obsolete already for GTK4: With Orca screen reader very oldest time when I developed Gtk3 applications, and when I tested missing labels in glade files with external apps I used a tool to automatic checking Glade files, the tool name is gla11y tool.
Link:
https://github.com/hypra/gla11y
Other possible useful link:
https://blends.debian.org/accessibility/tasks/devel

if tool is not obsolete already for GTK4, perhaps easyest your work, or automatic CI/CD integration designing for GNOME applications main Gitlab repositoryes. Of course this tool is not equals the manual testing, but oldest time me this tool helped founded and collected the trivial issues by applications level, without I need manual looking tab and SHIFT+TAB key combination all windows and dialogs to detect all objects are focusable, not need me open all dialogs with all page tabs to detect the trivial issues. Some time if I detected a trivial easy fixable thing (for example a missing mnemonic_vidget property a label related, or missing underline mnemonic character a control label related), if not have UI freeze or string freeze, I sent the proper tested full ready patch the affected application developer in Bugzilla, and I described why need fixing this issue to provide he's application better screen reader compatibility. Usual the full ready fix developers accepted and committed the fix the proper source repository.

In GNOME level I think have a relative good Accessible development documentation, all keyboard level code practices and standards for accessibility are documented, the documentation is accessible and readable. The practice is very simple, the developers need doing two things designing and development work related: - Designing level need fill the required trivial properties (for example if define a label a combo box related, please set the mnemonic_vidget property in Glade3 the proper combobox related), or fill a tooltip an image button related, or if not would like developer doing a screen visible description, fill the accessible description the button label, and voala, Orca says the right wanted object description, similar in HTML a link text, or an aria label.

- Second, vhen the dialog is ready, in designing level the developer simple need test the new window, without a mouse only a pure keyboard and screen reader. All dialog elements are focusable keyboard? If yes, fantastic, we step next task. Screen reader reads the proper description with focused objects? Yes or no? If no, fix the visual vidget proper object property designing level (not after application is released), and forward next task. :-):-) Possible this is not always possible, but designing level easyest doing this things future.

Gnome accessibility developer documentation link:
https://developer.gnome.org/documentation/guidelines/accessibility.html

GNOME accessibility Wiki:
https://wiki.gnome.org/Accessibility

Perhaps outdated testing wiky:
https://wiki.gnome.org/Accessibility/Testing

Samuel, the gla11y tool is obsoleted or still work and compatible with GTK4 Glade files to easyest CI/CD integration implementation with GNOME3 Gitlab application source repositoryes, and easying Lukáš work or other GNOME upstream developers work, independent works for Red6 or not?

The longer purpose is perhaps following, Linux distributions independent I think: We need determine Linux distributions independent better quality assurance requirements step up, and determine a minimum quality to an UI design what trivial fixes need resolve before developers have final commit the final results and releases a GNOME or Mate release. Perhaps the section 508 accessibility rule sets this quality assurance is defined, but I am not full sure this. Section 508 is only USA level accepted, or world wide level?
I found only this link:
https://www.section508.gov/manage/laws-and-policies/

I say a very positive example since 12 years:
For example Liblouis level a language Braille change must meet very strict quality assurance requirements before it can be included in the Liblouis main source repository. The Braille table or a code-level change must pass the defined international language corpus tests and the code-level tests that you defined recently before version 3.22 (no memory leaks, no other problems, etc.). Automatic CI/CD accessibility problem testing need At the Gnome level, this phenomenon should be addressed, not Linux distributions level, to avoid fragmentation with various fixes. This way, not only the Fedora distribution could benefit from the results, but any open source distribution that uses the GNOME release.

A second, only technique question for you:
With screen reader you what designing tool use when designing UI windows for GTK applications? Oldest time I used medimum level the Glade3 application (version is the 3.22.1 version if remember right), but if I remember right, the newest versions the palette window and designing area is not very accessible for screen reader. For example the TAB and SHIFT+TAB key combinations if I remember right not works the newest version, but I now not have possibility to verify for you this for example an Arch Linux virtual box.

In the Glade 3.22 version when I developed and designed a hungarian Braille Editor application for hungarian visually impaired people (the application called with Infoalap Braille Editor), because in the IT Foundation for the Visually Impaired - Hungary only me have knowledge and experience to doing the designing related works to provide maximal screen reader compatibility, when I doed the designing related works in Glade, I more time need use previous the flat review feature in Orca. But the Glade 3.22.1 version in palette window possible move TAB and SHIFT+TAB keys and have possibility to click the right control in palette window and designer areas if I need place the future application or dialog window a check box, combo box, edit box, normal label, etc. After this, the object inspector or I think the proper component property editor window I simple need customize the properties. For example if the palette window not spoken orca right the proper control label (for example a future check box control with I need adding the future application or dialgue designed window), I simple need press CTRL+F1 key and the tooltips are vonderful spokened when I require.

So, in the application development cicle I wonderful designed the final dialogs and windows in the Glade 3.22.1 version, the full app is wonderful accessible designing level with screen reader. Hopefully future I get back this freedom once for Glade3, or an another designer app for GTK4.

So, congratulate for your new work, and thanks if you have suggestion for me with Glade3 screen reader usage related.

Sorry if my english is not always right, my primary language is hungarian.
Kind regards,

Attila Hammer


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]