Accessibility Minutes 2014 08 25
From MemberWiki
Contents |
Present
- Jon Gunderson (University of Illinois) - Chair
- Ann Abbott (IBM)
- Marc Johlic (IBM)
- Nicholas Hoyt (University of Illinois)
- Mike Scott (State of Illinois) - Scribe
Discussion
Meeting Schedule
Next meeting Sept 15
Move to twice a month, or alternate weeks on rules/tools?
Finishing rules for 1.0
Need to talk about rule groupings
Grouping rules could help support training
Grouping would be optional
Allow users to select what is most appropriate to meet their needs
Update on AInspector Sidebar
Fixed problem with keyboard shortcut to toggle sidebar (took it out)
New feature to delay evaluation for 5 - 60 seconds to allow tester to interact with page, show dynamic content, etc.
Sidebar may update automatically (need to test)
Update on FAE 2.0
Support for shibboleth single-sign on protocol https://shibboleth.net/
Support for authentication to websites
Both need to be tested
FAE Auditor - tool to evaluate and report on multiple websites
Being used on over 400 websites at U of I
May be interesting to use on State of Illinois websites
Used bootstrap.js to make FAE Auditor prototype adaptable to different screen resolutions
FAE Auditor tables are accessibily sortable using bootstrap
May be able to write rules & techniques to ensure that bootstrap is used accessibly
Need to look at mobile accessibility
Priority at UIUC right now to bring websites into WCAG 2 compliance
IBM not interested in testing tools that require sending data to outside servers
IBM uses Dojo & JQuery UI libraries
Dojo Dijit widgets conform; Dojo X widgets don't
Rules for WCAG 3.2.2
Consistent behaviors
http://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change
http://www.w3.org/WAI/WCAG20/quickref/#qr-consistent-behavior-unpredictable-change
Providing submit buttons - requiring explicit user action to submit form
Eval library keeps track of form elements; looks for submit button as child
If it finds other buttons, requires manual check
If not buttons, fails check
Technique suggests that value (text on face of button) indicates that it will submit form; test doesn't check for this (yet)
May be too many appropriate possibilities, "Go", "Move funds", "Check out", etc, to test
Using link to submit form would fail (without role=button on link)
Trying to avoid automatic change of context (form submission) when last field is completed. Not a perfect test for this.
Could make it always a manual check, but we have a lot of those
Like to pass people where we can; can change the rule if people abuse it
Could look at onchange or onblur event handlers, but would have to look at what the handler does, which would be difficult
Failures for SC 3.2.2 - On Input
F36: Failure of Success Criterion 3.2.2 due to automatically submitting a form and presenting new content without prior warning when the last field in the form is given a value
http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F36
F37: Failure of Success Criterion 3.2.2 due to launching a new window without prior warning when the status of a radio button, check box or select list is changed
http://www.w3.org/TR/2014/NOTE-WCAG20-TECHS-20140408/F37
F76: Failure of Success Criterion 3.2.2 due to providing instruction material about the change of context by change of setting in a user interface element at a location that users may bypass
If checkbox or radio has onclick, manual check to verify that it doesn't change context
If select has onchange, manual check to verify that it doesn't change context
Might this fit better with 3.2.5 AAA?
Also supports usability
Next meeting Sept 15