On 6/2/07, Jason White <[EMAIL PROTECTED]> wrote: > If this technique turns out to be useful, the benefits would lie in better > software quality generally, and also in improved accessibility support. > Amenability to automated testing could also constitute an additional > motivation for supporting accessibility-related API's early in project > development, and for keeping that support current. > > It would also make many accessibility-related bugs visible to application > developers (as test failures) and help to ensure that most of the work > involved in getting accessibility right would lie where it should - with the > authors of the user interface. > > What do others think?
+1. Taking that approach should reduce some gaps in QA. Some testers avoid testing via UI as that tends to be fragile with minor UI changes breaking tests. But if accessibility is seen as an aspect of usability then frequent small changes to the UI is bad for users. Using an a11y API reduces that fragility to some extent by providing some abstration as well as adding testing of those APIs as you say. In addition UI testing is required as that is how users access the software and if you don't automate it you are QA incomplete (ignoring CLIs/script/declarative). More importantly changes can break AT access. Testing this way should force more thought about trivial changes to the UI and impact on a11y. Perhasp it will one day become natural. However test applications that way may only access some of the exposed a11y functionality so further specific a11ying test is be desirable to ensure AT is properly supported. -- Steve Lee -- Open Source Assistive Technology Software PowerTalk - your presentations can speak for themselves www.fullmeasure.co.uk _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
