Implementing accessibility non-regression check tool

[Samuel Thibault]

Hello,

Samuel Thibault, le lun. 12 févr. 2018 15:30:59 +0100, a ecrit:
> - At some point we'll get confident that we won't introduce other
> big classes of warnings over hundreds of .ui files. That's the point
> where we can say "ok, let's start fixing the existing issues over
> all .ui files once for good". We can then run through .ui files one
> by one, fixing the issues and removing the corresponding suppression
> lines. These could be used as "easy hacks" entries, they are usually
> just a few lines to fix.

I believe we have gotten to this point, and it can now be time to start
fixing warnings.  I have completed documentation on fixing them on

https://wiki.documentfoundation.org/Development/Accessibility

and notably

https://wiki.documentfoundation.org/Development/Accessibility#Fixing_existing_issues

provides this kind of procedure to fix warnings: just remove suppression
rules for a .ui file, fix warnings in the .ui file or mark them as false
positives, submit the result, and move on to another .ui file.

Could people check this documentation before we advertise it more
broadly as an "easy hack"?

> The progression of all of this could be monitored with statistics
> reported e.g. in the minutes of ESC calls.

They could be gathered from e.g. the nightly build logs by grepping for

"\([0-9]+\) suppressed by .*\.suppr"

and adding the figures. I however don't know where such scripts live or
even their language :)

Samuel