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

[Hammer Attila <hammera pickup hu>]

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