As we are all aware, Accessibility is a bit different than other components of Drupal as far as bug reporting goes. With some components a particular task or feature can be said to work, or not. For example, if something regressed and the "Save" button for nodes suddenly stopped working (doomsday apocalypse) it would be pretty clear that this would represent a critical bug. With accessibility the critical nature of a bug is much less clear. A situation that may make a function or module completely unusable for one group of users might be unnoticed by another.
I want to put forth a proposal that for the Drupal 8 (D8) development life-cycle that we adopt the WCAG 2.0 priority levels as the starting place for issue tracker bug priorities.
- If an accessibility bug is reported showing that a particular aspect of D8 is failing a priority A success criteria, then that bug be marked Critical.
- If an accessibility bug is reported showing that a particular aspect of D8 is failing a priority AA success criteria, then that bug be marked normal.
- If an accessibility bug is reported showing that a particular aspect of D8 is failing a priority AAA success criteria, then that bug be marked minor, or perhaps as a feature request and not a bug.
Note: I believe that these are good guidelines to be used in the majority of cases. Clearly, if a WCAG 2.0 p. AA issue arrises which can be argued to criple functionality for a particular group of users, then this bug should be marked critical as well.
Would appreciate thoughts and feedback, and would like to build a broad consensus on this proposal.
Resource:
Comments
It's been great to see the
It's been great to see the growing accessibility efforts. Historically, 'critical' meant Drupal not working anymore. With the increased attention to UX and accessibility we can push to use 'critical' status for bugs that let People not work with Drupal anymore.
Your proposal sounds like a sensible initial approach. A new 'major' level was announced but has not materialised yet, it would be for 'very bad but not release blocking issues'.
Major bug priority
@yoroy
Thanks for the comment.
I think that We should have four priorities not three (introduce a new 'major' priority) will be quite helpful in a number of ways, including accessibility.
Depending on the definition of Major versus Critical, I would revise my proposal above. WCAG 2.0 priority A issues should still be critical, priority AA issues may be Major and may be Normal, depending on the effect of the issue, priority AAA issues should remain minor if filed as bugs, but might also be filed as feature enhancements.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Nice Initiative!
I definitely think this is the way forward. It ensures that everything in Drupal 8 is at least WCAG2.0 priority A compliant. Having that base level of compliance from the beginning will be a huge advantage to the Drupal community.
Like any standard, I'd agree that if a feature breaks xHTML Strict compliance it should be marked critical. This approach will help everyone remember the importance of standards & remind everyone what we are aiming for!
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
Nice!
I agree--this kind of process would be really helpful and provide a clearer basis of what is and what isn't 'critical'.
Is this the kind of thing that will be discussed at the Core Developer Summit at DrupalCon SF?
www.pixotech.com
Core Developer Summit
I'm certainly planning to be there and will be championing this position for D8. Everett, are you going to be there on Saturday? Anyone else from this community planning to be there then?
Looks like they are doing lightning talks - http://sf2010.drupal.org/conference/core-developer-summit
So, who is planning to be there and what should we organize around?
--
OpenConcept | Twitter @mgifford | Drupal Security Guide
I'll be there!
I'll be there, perhaps a little sleepy from my flight, but bright-eyed and eager to listen and contribute. This is awesome, Mike! :)
Won't be at core developer's summit
I likely won't be at the core developer's summit. I think my flight is coming in later in the day.
On an unrelated note, I'd love to hear from anyone interested in lending me an elbow for a few hours during the conference. Please contact me privately if interested and available.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
At Sunday CiviCRM then DrupalCon but not summit
Hello all,
I'm looking forward to connecting with some of you at DrupalCon again. I've been tracking this group with great interest but overly-busy as the only Drupal person on re-engineering http:www.daisy.org - the Digital Talking Book Specification. I have CiviCRM and Atrium private groups on the back end - not yet live.
George Kerscher as DAISY Secretary General and a screen reader user (http://www.georgekerscher.com/ - soon to be Drupalized by George) has been using and tracking Drupal re accessibility and he asked me for a report re Drupal yesterday before a conference call as Chair of the Steering Council Web Accessibility Initiative (WAI).
George is also President of the International Digital Publishing Forum (IDPF) which develops the EPUB standard. The EPUB issue tracking is in Drupal with only navigation & style mods for accessibility guided by George at http://www.daisy.org/epub.
One reason to introduce George's credentials is that I asked him for ideas re a recent post re Drupal accessibility projects for GSOC. He expressed a lot of interest in the "accessible WYSIWYG" idea but as a contributor to the W3C XHTML spec, he would also be very interested in an accessible HTML editor since he has to generate all of his input offline in an editor that produces valid code. A desirable function for me also would be the ability to find and replace HTML tags in the source of a node.
Should I start another topic on this list or enter as a GSOC proposal - or both?
Best - Kathy
GSOC
@Kathy
Excited to meet you at Drupalcon. Can I recommend adding comments to Brainstorming for an accessibility proposal. I'm sure there are others who would help in developing the proposal. I'd also love it if you, could help us find an interested student to apply to work on the GSOC proposal. This is a little off topic for this current thread.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Will be attending core developer summit
Well, got my flight booked today and I will be arriving in SF at 9:30am, so I will attend the Drupalcon core developer summit.
For anyone interested in attending please visit Drupal core developer summit at DrupalCon SF. You have to submit a slide presentation to get an invite.
Accessibility Consultant & Web Developer - Zufelt.ca
@ezufelt on Twitter | LinkedIn profile
Form API/labeling for D8
Here is a rough draft of the presentation I'm going to submit for the Core Developer Summit. I'd appreciate any feedback.
Why Form API accessibility sucks and how to improve it
What Sucks
What Sucks #1: No fieldsets
What Sucks #2: Partial Support for 'invisible' labels
What Sucks #3: FAPI
Bonus Suckage #4: Form Errors
How to improve it: fieldsets
How to improve it: labels and FAPI
How to improve it: errors
In summary, I'm eager to help make this happen. Tell me who to coordinate with and how to get connected with the right people to enhance Form API in an accessible way.
www.pixotech.com
A Suggestion for #4 Form Errors
Good presentation at DrupalCon. Thanks.
Here is a wild idea for solving this problem that need not even wait until Drupal 8.
To the sightless person, the red border around the text box does little good. The error summary at the top is more useful.
However, why not use text to speech technology as well. We could have a module that triggers an audio message when the page reloads with an error. In effect it reads a certain type of error message. It could say:
"THE ZIP CODE FIELD IS REQUIRED BUT HAS NOT YET BEEN FILLED IN. IF YOU PRESS (Some key Combination) IN THE NEXT FIVE SECONDS, YOU WILL BE TAKEN TO THE ZIP CODE TEXT BOX FOR ENTRY."
If the module is enabled, the user can be given the option to turn it on or turn it off in the user profile, The number of seconds can also be set individually.
Some of us who are sighted would use this.
Except for the timer, that's great!
You don't want a timer because a person who has a mobility impairment or a cognitive disability might need more time than whatever interval we might arbitrarily choose. The best practice is to leave the control of such transitions up to the user. (Think of the waiter who removes the plate before you've had a chance to get that one tasty morsel you were leaving for the end because you like it best. Don't be overly helpful; you'll frustrate the user by getting in the way.)
But this is similar to a proposal we made that does follow best practices: When there are form errors, put a brief explanation of each and how to fix it (for example, "Street Address is required. Please [link]complete street address[/link]." And that's not the greatest example, but I hope you get my general point: Above the first form field, explain the mistakes and link to the respective field from each explanation. That way, it works for everyone.
Because people who cannot see would be using a screen reader or, if deaf-blind, a text-to-Braille form of assistive technology, there is no need to have an audio message. Their assistive technology converts it to the right format for them.
But I really like that you're thinking about it, @leigen. It never hurts to suggest a fix. Either you learn a little more or your suggestion fixes the problem. That's a win-win!