Kyle <kyle4je...@gmail.com> wrote: > Rather than making a11y out of sight out of mind for specific application > developers, my thought is that an a11y component could, if handled > correctly, bring it into focus. Ideally, the a11y component would > automatically send the bug to the a11y team, who would in turn be able to > make specific comments, suggestions and/or patches and send the bug report > along with all the extras to the specific application development team. If > done this way, it puts more eyes on the bug report and more hands on the > code, which IMO is a good thing(tm)
How many people in Gnome other than accessibility specialists kno how to diagnose and fix a11y bugs that might appear in components/applications that they maintain, and how to avoid introducing them in the first place? This needs to be similar to internationalization: everyone who works on user interfaces should be expected to know what functions to call to obtain localized strings etc. Similarly, everyone should know at least a little about the accessibility infrastructure and what to do/not do in their code. Those who extend UI toolkits (whether in virtue of working on the toolkits themselves or by writing custom components for applications) needs to know more. Updating the developer guide would be a positive step, but then, relevant people need to read it and take this into account in code they write or modify. _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
