This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Bugzilla is a major component in the HTML Decision Process, which states "Issues should be filed as bugs in W3C Bugzilla to be formally considered." Accessibility/usability problems have been identified. http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0146.html I know Paul said that he would watch the comment list and assist people if they have trouble, which is helpful. But it would be great if people could file bugs directly without encountering major accessibility/usability problems. Thanks. References: http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0152.html http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0164.html http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0421.html http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0424.html http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0428.html http://lists.w3.org/Archives/Public/public-html-a11y/2010Mar/0435.html
Actually this isn't a bug that's specific for HTML5, it affects the entire W3C bug tracking system. Max Kanat-Alexander who works on Bugzilla in Mountain View sent me a tweet that accessibility should be improved with version 3.6 [1] The installed version at the W3C is 3.2.6. I'd suggest updating to a current version and switching to UTF-8 (checking data integrity might be necessary afterwards). I'll try to find out if and how the templates could be adapted then. In the meantime Paul Cotton raised the issue 2010-09-01 with the W3C systems team where it will be taken care of. Therefore I'd suggest to close the bug here. Cheers, Martin [1] http://twitter.com/mkanat/status/22852456145
(In reply to comment #1) > Actually this isn't a bug that's specific for HTML5, it affects the entire W3C > bug tracking system. > > Max Kanat-Alexander who works on Bugzilla in Mountain View sent me a tweet that > accessibility should be improved with version 3.6 [1] The installed version at > the W3C is 3.2.6. > > I'd suggest updating to a current version and switching to UTF-8 (checking data > integrity might be necessary afterwards). > > I'll try to find out if and how the templates could be adapted then. > > In the meantime Paul Cotton raised the issue 2010-09-01 with the W3C systems > team where it will be taken care of. Therefore I'd suggest to close the bug > here. > > Cheers, > Martin Hi Martin, Many thanks to Paul for raising the problem with the W3C systems team. Yes, Bugzilla accessibility/usability problems affects the entire W3C bug tracking system. However, it is specific to HTML5 because HTML5 is relying on Bugzilla as a major component in its decision process. I expect many people will be trying to use Bugzilla to raise bugs on HTML5 and encounter the same problems that Gregory encounterd. http://lists.w3.org/Archives/Public/public-html-a11y/2010Jul/0146.html It may discourage HTML5 input and shut some people out of the process. Other W3C groups seem to have made modifications to Bugzilla, for instance WCAG: http://trace.wisc.edu/bugzilla_wcag/ http://trace.wisc.edu/bugzilla_wcag/issuereports/ They also seem to use a different comment form: http://www.w3.org/WAI/WCAG20/comments/onlineform It might be helpful to get some advice from the WCAG folks.
PROBLEM: every time a new comment is logged, a "Reply" link is generated which allows threading of comments -- such repeated link text, however, is not programmatically bound to the comment number to which it refers, with the result that there are numerous links named "Reply" whose function is identical (create a reply to the comment) but which cannot be differentiated from one another nor easily associated with a specific comment SUGGESTION: explicitly include the number of the comment in the Reply link (e.g. "Reply to Comment #16" so as to avoid having multiple links with identical hyperlink text) (although one could use WCAG 2.0 Technique C7 to use a CSS overlay to hide the comment number portion of the Reply hyperlink from visual renderings, i think there is utility for ALL users if each "Reply" link explicitly refers to the comment to which one is using the link to reply)
PROBLEM: collapse/expand link undecipherable if one cannot read document source currently, one can expand or collapse individual comments using a hyperlink whose hyperlink text is "(-)" or "(+)", which constitues ASCII art, which must be either 1. glossed using ABBR <ABBR title="Collapse">(-)</ABBR></a> <ABBR title="Expand">(+)</ABBR> 2. use the actual terms "expand" and "collapse" as the hyperlink text 3. use an expand/collapse graphic with proper alt text <img src="collapse.png" alt="collapse"> <img src="expand.png" alt="expand"> RECOMMENDATION: of the 3 approaches outlined above, i strongly recommend #2 (use the actual terms "expand" and "collapse") because one cannot count on a user of assistive technology to have abbreviations set to auto-expand, although it is a valid solution to the problem of indecipherable hyperlink text
PROBLEM: the term "comment" should be included in the link to the individual comment number currently, comments appear as hyperlinks with the hyperlink text "#x" (where "x" is the actual number) PRECEDENT: the auto-generated in reply to "comment #x" includes the word "comment" along with the actual number;
Further information from the Bugzilla engineers: "We're adding more ARIA as we go. There are still a lot of tables. The templates are Template Toolkit, they can be edited." [1] So if the W3C finds the resources, the templates could be improved. Under the Mozilla Public License (MPL) the W3C could even make the enhanced template code available to the Bugzilla project, thus further impacting the accessibility of the tool beyond the internal use at the W3C. [1] http://twitter.com/mkanat/status/22924980935
(In reply to comment #6) aloha, martin! thanks for following up on this with those working on bugzilla -- i would be more than willing to work on a team that (a) increases the accessibility of bugzilla, (b) increases the usability of bugzilla, and (c) is ported "upstream" to "vanilla bugzilla" so that anyone using bugzilla out of the box can be assured that there are accessibility and usability features built into bugzilla i have used this bug to document additional problems and proffer suggestions which supplement the issues that i documented in the initial bugzilla accessibility post to public-html-a11y@w3.org and i have a few others... what course would you advise me to take? i think we need some people to work on the issues identified so far in conjunction with the W3C systeam, and i am consequently volunteering -- has mkanat provided a list of the accessibility improvements slated for the next release or do you know if such a document exists? it would be helpful to ascertain what the bugzilla developers have already done and already committed-to so that work on the bugzilla interface can be as focused as possible, gregory.
@Gregory, I believe it would be best to connect you with Max then. I'll contact him on twitter and point him to your initial assessment and this bug.
the email produced by bugzilla contains a visually-oriented summary of the bug's status, which is difficult to parse using speech output or any other non-visual medium; for examnple: What |Old Value |New Value ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | a more useable and accessible way to display this information would be through the use of a bulleted lists, as follows: Status: * Old Value: RESOLVED * New Value: REOPENED Resolution: * Old Value: WONTFIX * New Value (none)
If the changes are going to be folded into Bugzilla, I'm also happy to pitch in with template repair measures, if another hand is needed.
Bugzilla instance at W3C now running 3.6.2, please review accessibility concerns raised earlier.
(In reply to comment #11) > Bugzilla instance at W3C now running 3.6.2, please review accessibility > concerns raised earlier. adding michael cooper, w3c staff contact for PFWG and WCAG -- notifications aren't going to the public-html-a11y@w3.org list -- i think this is due to the change in the from: field, which is now bugzilla-daemon@jessica.w3.org and not bugzilla@jessica.w3.org as previous
(In reply to comment #11) > Bugzilla instance at W3C now running 3.6.2, please review accessibility > concerns raised earlier. aloha, ted! thank you very much! i will comment further and coordinate bug submission on the bugzilla.org's bugzilla as time permits; NOTE: the keyword for accessibility at bugzilla.org is "access" 2 problems to report with the "Help" link: 1. the "help" link that points to: http://www.w3.org/Bugs/Public/docs/en/html/query.html#lists leads to a 404 error also (in something that needs to be addressed at the bugzilla.org level, perhaps, unless you are comfortable editing the templates, is to remove the target="_blank" from the "Help" link, as that forces open a new tab or browser instance, which can severely disorient a user -- if you can't do anything about this right now, i will log it as a bug on bugzilla.org's bugzilla and add it to the list of the accessibility issues for the w3c team of volunteers to address
docs lined up better I removed from our copy of the templates various occurrences of target="_blank", it would be better if you can persuade those to be removed upstream.
The HTML WG Chairs are attempting to determine if this bug can be closed since it is anchored on the HTML WG Decision Policy. Have the problems in this bug been fixed by installed a more recent version of Bugzilla? See comment #11: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10525#c11 /paulc
The bug-triage sub-team doesn't think this should be task force priority because it's an external tool, but we encourage individuals to look into the accessibility of the tool and make recommendations or improvements.
By the way, Bugzilla version 4 was released a couple of days ago, so a comparison between the currently installed version and the latest version would make sense.
It is regrettable that bugzilla is lacking in some aspects. However, resolving these issues seems out of scope for the decision policy document. There is no component for tools in the W3C bugzilla. I recommend reporting these issues to the W3C Team and/or upstream to the bugzilla maintainers: http://www.bugzilla.org/developers/reporting_bugs.html
Bugzilla is not currently compliant to the WAI WCAG as far as I am aware. Whether or not it is Section 508 compliant, I do not know. However, one solution here could be to set up Bugzilla's email_in interface. Then users could at least provide their feedback on bugs (and file bugs) via email. As long as you can accept the possibility of impersonation, and you have no confidential bugs, using email_in.pl should be fine.
By the way, the IBM Linux Technology Center is also currently contributing WAI WCAG fixes to Bugzilla upstream, and we expect some (if not all) of them to land in 4.2. Some of the major interfaces have already been fixed on trunk.
Hi Max, You wrote in Comment 20: > By the way, the IBM Linux Technology Center is also currently contributing WAI > WCAG fixes to Bugzilla upstream, and we expect some (if not all) of them to > land in 4.2. Some of the major interfaces have already been fixed on trunk. Would you recommend installing the latest Bugzilla release then?
(comment #9) > the email produced by bugzilla contains a visually-oriented summary > of the bug's status, which is difficult to parse using speech output > or any other non-visual medium Reference: http://lists.w3.org/Archives/Public/public-html-a11y/2011May/0492.html
(In reply to comment #21) > Would you recommend installing the latest Bugzilla release then? Well, I would certainly recommend that as a general measure. :-) But 4.2 is the *next* release, not the current one. (In reply to comment #22) > > the email produced by bugzilla contains a visually-oriented summary > > of the bug's status, which is difficult to parse using speech output > > or any other non-visual medium True. Bugzilla 4.2 will have HTML emails that might be easier for a screen-reader to handle. However, my suggestion was for inbound email, so people could at least send in comments without having to use the web interface.
(In reply to comment #23) > (In reply to comment #21) ..... > However, my suggestion was for inbound email, so > people could at least send in comments without having to use the web interface. You failed to comment Laura's reference to my e-mail, where I cited from the Bugzilla features description: ''' All of Bugzilla's User Interface and every email that Bugzilla sends are generated from "templates", files that contain mostly just HTML, CSS, and JavaScript. Depending on how far you want to customize your installation, you don't have to know Perl to customize Bugzilla, you just have to edit the templates! ''' http://www.bugzilla.org/features/#extensions So, given that a mayor problem is the visual orientation of the plain text messages that Bugzilla sends out, do you think that it - by editing the templates - it would be possible to make Bugzilla send out more accessible plain text e-mail reports? And, btw, with regard to the upcoming support for HTML e-mail, is it perhaps possible, even now, to send out HTML e-mail, if only one is willing to struggle with the templates?
Related thread on public-html: http://lists.w3.org/Archives/Public/public-html/2011May/thread.html#msg268
Related email: "Hi Maciej, > The following proposed revision of the Decision Policy resolves nearly all > outstanding bugs, including such frequent requests as defining the process > for reopening an issue, and defining the process to be followed for the LC > Review period. Comments welcome: > > http://dev.w3.org/html5/decision-policy/decision-policy-v2.html Systems used in the decision policy should be accessible for use by persons with disabilities. Currently the decision policy and Last Call may lock out people who want to provide the HTML Working Group feedback because the HTML Chairs choose to use Bugzilla which currently has accessibility and usability problems. It seems that the HTML Chairs as well as the W3C are responsible and would be liable for this choice. Problems were identified to the Chairs in the September 1, 2010 Bug 10525 [1] which you marked INVALID May 16, 2011." Source: http://lists.w3.org/Archives/Public/public-html/2011May/0313.html
I'm taking ownership on this bug.
Related: http://www.w3.org/html/wg/tracker/actions/203
Can somebody confirm that the UI of the bugzilla instance at http://trace.wisc.edu/bugzilla_wcag/ does in fact have changes that fix the problems that Gregory has cited? Gregory, have you used that instance yourself?
Would it help to have the bugzilla e-mail interface enabled in the W3C bugzilla instance? What I mean is this: http://www.bugzilla.org/docs/tip/en/html/api/email_in.html And I mean more for the case of modifying existing bugs rather than the case of creating new bugs (because we have the comments list already as an alternative for that). Specifically, Gregory, would you find the e-mail interface useful as an alternative, and/or do you think others would? If it seems like it would be useful, I can discuss it with the W3C systems team. But if not, I won't pursue it any further.
Note for the record here that I've set up a way to help ensure that bugs are created for any new comments posted to the public-html-comments list: http://lists.w3.org/Archives/Public/public-html/2011May/0382.html So, we can let the wider community outside the group know that have the choice of using the comments list for filing last-call comments, as an alternative to raising bugs in bugzilla directly, and they can be ensured that their comments will get recorded and tracked and considered just as they would be if entered directly in bugzilla. I do of course still plan on helping to get the a11y problems in the current UI fixed, but regardless, for the bug-creation case, posting to the comments list will continue to be a good alternative.
Update: In the interest of taking some baby steps on fixes, I hacked some on the bugzilla code today to improve the readability/accessibility of the e-mail notifications that bugzilla sends out. The result is that in place of the ascii-table-layout formatting that bugzilla currently uses, we'd get something like the following instead: [[ From: bugzilla-daemon@sideshowbarker.net To: mike@w3.org Subject: [Bug 1] checking e-mail Date: Mon, 20 Jun 2011 16:00:37 +0900 http://sideshowbarker.net/bugzilla3/show_bug.cgi?id=1 sideshowbarker+foo@gmail.com changed: Priority Old: Normal New: High Status Old: ASSIGNED New: RESOLVED Resolution Old: New: WONTFIX Severity Old: critical New: blocker --- Comment #5 from sideshowbarker+foo@gmail.com 2011-06-20 16:00:37 JST --- this is a comment ]] Comments welcome on whether that's an improvement or not. I also raised a related bug upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=665419
(In reply to comment #32) > Update: In the interest of taking some baby steps on fixes, I hacked some on > the bugzilla code today to improve the readability/accessibility of the e-mail > notifications that bugzilla sends out. > > The result is that in place of the ascii-table-layout formatting that bugzilla > currently uses, we'd get something like the following instead: Yes. replacing the ascii-table-layout with what you proposed would be an improvement. Many thanks for your work on this, Mike.