310568 - Reporter: Include "Disability access broken" as "Problem type" option

Status: RESOLVED FIXED

(Other Applications Graveyard :: Reporter, enhancement)

Description

[Aaron Leventhal]

It would be excellent to use the reporter tool to empower users to report which
websites have accessibility problems.

Comment 1

[Aaron Leventhal]

Alternatively, we could make sure people understand this with
"Access for people with disabilities"

Comment 2

[Aaron Leventhal]

Attachment: Add "Disability access" as problem type option

How do I solve these problems?
First, should "other" must be moved to item "8" or should it stay "7" for
consistency with Firefox beta 1?

Second, I get this build error:
Comparing ar to en-US
Entities in ./chrome/reportWizard.dtd don't match:
  In /cygdrive/c/moz/mozilla/extensions/reporter/locales/en-US: (add these keys
to you localization)
    reportForm.problem_type.item8.title

Comment 3

[Robert Accettura [:raccettura]]

It should stay consistant in terms of the value (value 7 should stay value 7 for
the life of the product).  They don't need to be in numeric order, just logical
order so that "other" should be last.

The entity names themselves really need to be renamed to something not numeric
to avoid future confusion (ie. reportForm.problem_type.other.title instead of
item7).  I've been meaning to do that.  I didn't bother thus far, since adding
items to that list will be a rare/never event.

Anything over 100 in value will be a "custom" field in the next version, for
cases of corporate deployment.  But we don't have that functionality just yet.

Comment 4

[Aaron Leventhal]

Attachment: Add "Disability access" as problem type option

Comment 5

[Aaron Leventhal]

Robert, how do I deal with the fact that it won't build until all the locales
have been updated?

Comment 6

[Robert Accettura [:raccettura]]

Comment on attachment 197995 [details] [diff] [review]
Add "Disability access" as problem type option

r=me, pending Asa's approval for the addition and the wording of it.

Comment 7

[Robert Accettura [:raccettura]]

(In reply to comment #5)
> Robert, how do I deal with the fact that it won't build until all the locales
> have been updated?

No clue.

cc-> gandalf

Comment 8

[Aaron Leventhal]

We should go with "Disability access broken" as the final wording, for consistency.

Comment 9

[Benjamin Smedberg]

It was my understanding that reporter was string-complete for the branch and
therefore this should not be approved on the branch. On the trunk, this should
be checked in and all locales except en-US should be removed from the list of
locales at
http://lxr.mozilla.org/mozilla/source/extensions/reporter/Makefile.in#55. As
locales update themself they can be added back to the list of locales to build.

Comment 10

[Robert Accettura [:raccettura]]

Still needs Asa's approval for the trunk, as that list is his domain.

Comment 11

[Axel Hecht [:Pike]]

This is an l10n nightmare that we won't be able to fix for beta2.
I suggest that we don't take it after beta2 either.

The administrational hurdles of fixing this 'til monday are way out, and even
'til wednesday would be *very* doubtful. And in the end, this is just an RFE.

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 197995 [details] [diff] [review]
Add "Disability access" as problem type option

It sounds like this isn't branch material, and I'd like to think about it a bit
longer before we make it trunk material.

I'm concerned about adding additional problem types that might confuse users.
This is intended to be a very simple tool and the current list of problem types
went through several itterations and reviews to get right. If anything, I've
been considering making the list even shorter.

I'm also concerned about the slippery slope here and absolutely do not want
this tool to start to become as prohibitively complex as Bugzilla with its
extremely long lists of components.

Comment 13

[Aaron Leventhal]

Asa, I think it's more confusing if accessibility problems get filed under all
the different categories. This tool has huge potential for accessibility
evangelism. It really is a separate class of content issues. Missing alt text or
non-linear layouts just don't affect mainstream users. I'll have to have people
file it under "Other" for now and include some text like "[a11y]" in their comments.

Comment 14

[Asa Dotzler [:asa]]

Aaron, this tool isn't for people we're working directly with. This is for more
"end user" types who we're not going to teach to use bugzilla. If you're
directing people to use this tool, please show them bugzilla's evangelism
component instead. This is like talkback and we intend to analyze these reports
in aggregate.

Comment 15

[Aaron Leventhal]

(In reply to comment #14)
> Aaron, this tool isn't for people we're working directly with. This is for more
> "end user" types who we're not going to teach to use bugzilla. If you're
> directing people to use this tool, please show them bugzilla's evangelism
> component instead. This is like talkback and we intend to analyze these reports
> in aggregate.

Exactly, I want this available to all people with disabilities. Most of them are
not sophisticated or patient enough to wade through Bugzilla. This would really
be a great empowerment tool in the hands of the masses of people with
disabilities! Accessibility is a separate problem grouping from the others there
-- sorry to recommend expanding your nice minimal list but there you have it :)

Comment 16

[Asa Dotzler [:asa]]

Seems reasonable to do this for releases without l10n concerns. 

Comment 17

[Robert Accettura [:raccettura]]

A few things:

1.  Asa: should we take this addition?  On the branch?  

For the record, we also have a bug (337484) to expand reporter to handle phishing reports, as well as one for taking the character encoding (that's not adding to the UI, just what we collect). 

2.  Server side needs to be modified to accept a new option.  As I recall it's just a config, but we need to get that done first.  This is more a reminder to myself.

Pending Asa's acceptance of this addition we can get a sysadmin to adjust the configs for the server, and this can land.

Comment 18

[Asa Dotzler [:asa]]

we should take this wherever it doesn't negatively impact localization.

Comment 19

[Aaron Leventhal]

Robert, can you make the server side adjustments now that Asa has given his approval?

Comment 20

[Robert Accettura [:raccettura]]

This is on my todo list for this week.  File a bug against me under webtool --> reporter for it.

Comment 21

[Robert Accettura [:raccettura]]

Server is now supporting this change.  You can land when ready.

Comment 22

[Axel Hecht [:Pike]]

Comment on attachment 197995 [details] [diff] [review]
Add "Disability access" as problem type option

Hrm. extensions/reporter/locales/en-GB/ is CVS removed on both trunk and 1.8 branch. How is this patch supposed to apply?

Comment 23

[Aaron Leventhal]

I got it when I did cvs up -d en-GB
So it's in CVS.

Comment 24

[Axel Hecht [:Pike]]

Compare http://lxr.mozilla.org/mozilla/source/extensions/reporter/locales/ to http://bonsai.mozilla.org/rview.cgi?dir=mozilla/extensions/reporter/locales/en-GB/chrome&cvsroot=/cvsroot&module=default

It is removed, and cvs update -P should tell you.

Comment 25

[Aaron Leventhal]

Okay, so it sounds like I should be able to check in everything but the en-GB change.

Comment 26

[Axel Hecht [:Pike]]

This is fine for the trunk, from a branch perspective, this is targeted at 3.0, right?

Comment 27

[Aaron Leventhal]

Yes, this is targeted to Firefox 3. Too late in the game for Firefox 2.