Re: Enable accessibility team to automatically receive bugmail on a11y bug reports

[Bryen M Yunashko <a11yrocks bryen com>]

I think this is great, and will make it much easier for those of us who
file bugs against accessibility.  Having a component, rather than
knowing to type in accessibility (or a11y?) in keyword will greatly
improve things in Bugzilla.

But I do worry about some accessibility bugs falling through the cracks
this way.  Not all accessibility issues are inherently part of what the
a11y team does.  Some fall into the grey area between accessibility and
usability.  This is especially true for low-vision users like myself who
do not use assistive tools software or require accessibility to be
enabled, but do need better customization or tweaking features within
software itself.

For example, a while ago, I filed a bunch of accessibility-related bugs
against Banshee.  One particular example is where a particular component
was not respecting my high-contrast theming.  In this case, while the
rest of Banshee was respecting it, when I pull up the lyrics panel, it
gives white background, which is extremely difficult to read.  

My neighbors are probably thusly relieved to not have to hear me singing
along with some songs on my computer.  :-)

I haven't received any feedback from the Banshee team on any of these
bugs.  However, I would assume (and correct me if I'm wrong), such fixes
are the responsibility of the Banshee team rather than the A11y team.
(Or whomever created the specific lyrics plugin.)  

I encounter devs from time to time who say they do care about a11y but
are somewhat intimidated by its complexity and thus feel reassured that
a11y is handled by an a11y team.  It then becomes an
"out-of-sight-out-of-mind" situation.  Using the above Banshee example,
I fear such a bugzilla component would further widen the gap between
devs and a11y team because it gets directed to a11y team rather than the
Banshee team.

How will this get handled and be given proper prioritization by the
respective teams?  How do we ensure that non assistive-technology
accessibility issues are dealt with in a timely manner?


Bryen M Yunashko


On Mon, 2012-07-30 at 15:19 +0200, Andre Klapper wrote:
> Currently accessibility (a11y) bug reports in random modules/products
> can only be found by querying for the "accessibility" keyword.
> 
> Bugzilla does not allow "binding" an email address to a certain keyword
> to automaticall create bugmail whenever a specific keyword is added.
> 
> Having accessibility enabled by default since GNOME 3.5, the GNOME a11y
> team expressed interest in better notification of a11y bug reports.
> 
> My proposal is similar to how most user documentation bug reports are
> handled currently (though this is not totally consistent yet either) and
> affects many projects using Bugzilla (hence CC'ing d-d-l).
> 
> 
> Proposal:
> Create a new component for each important (core, core applications?)
> product/module in Bugzilla called "Accessibility". 
> By default assign any bug reports in this component to a (yet to create)
> specific account, e.g. "accessibility-team gnome bugs".
> People that want to follow a11y bug reports could add this account to
> their watchlist at the bottom of
> https://bugzilla.gnome.org/userprefs.cgi?tab=email to receive bugmail.
> The "Default QA" field remains as it is (means: a11y reports are still
> watchable for the actual module developers, as before).
> 
> 
> Currently two Bugzilla products already have an "Accessibility"
> component: Empathy and Ekiga.
> However, in both cases the default assignees are the Empathy/Ekiga
> maintainers and not the a11y team.
> 
> The keyword "accessibility" exists and has 973 open tickets in Bugzilla.
> For those products (core, core apps etc) that I'd create the new
> "Accessibility" component, I'd probably move any reports with this
> keyword to the new component. I think we should keep the keyword for
> those modules/products that are not core apps.
> 
> 
> If there are no concerns (or proposals how to do this in a better and
> less disruptive way), I would go ahead with this in a few days.
> Hopefully.
> After setting up the new components, bug triagers and developers should
> move new incoming a11y reports into the new "Accessibility" component of
> their respective product.
> 
> andre