One of the ways to get things fixed in browsers, or at least understand why things aren’t/won’t be fixed, is to file a bug. I spend a fair bit of time filing and commenting on bugs. (Updated to include reference to Opera bug report wizard)
For accessibility bugs Mozilla Accessibility Engineer Marco Zehe advises
Use product Core, Component Disability Access APIs, and we’ll take it from there.
“Firefox: Disability Access” will also work, but usually we assign it to the other product/component straight away anyway.
Example bug: HTML5 main element not supported
Advice from David Storey:
If you can:
- Also include a reduction that just shows issue.
- Include real world site it affects as (at least for IE and Opera in my experience) a bug that affects real world sites have higher priority as it breaks things.
You need a Google account to file bugs.
Example bug: hr element not exposed with a separator role
- Report bugs
- Open Accessibility bugs list
- Bug Reporting Guidelines for the Mac & Linux builds (with links to known issues pages)
- Instructions for reporting crashes.
As an example of things to do when writing a bug report, the IE bug reporting guide is excerpted below:
Before Filing a New Bug Report
Ensure you’re running the latest version of the browser, since your issue may already have been resolved in a newer version.
Search for existing bugs in the bug database to see if your issue has already been reported.
Try to identify specifics steps that would allow us to consistently reproduce the issue you’re seeing, if possible.
Please file separate bug reports for each problem encountered.
Key Components of a Good Bug Report
A good bug report has a clear and concise title (usually less than 15 words). Summarizing your problem concisely improves our ability to understand and fix bugs.
Good: “[browser version XX] Unable to type in search box of www.example-url.com”
Bad:“Search functionality broken”
A good bug report clearly explains what you were expecting to see, and how it differs from what you actually saw happen. We’ve found that both of these perspectives are valuable and help us fix more bugs. For example, describing your expectation can help us fill in gaps and fix bugs that otherwise might not be reproducible, since bugs sometimes depend on external factors like the language of the underlying operating system.
Selecting the correct area
A good bug report has the correct area selected. We want to get your bug report to the right developer as quickly as possible, and selecting the correct area in the form helps. Since some issues might fall under more than one area, try searching in the bug database to find similar bugs in that area.
Precise, reproducible steps
A good bug report is descriptive and easy to follow. A clear step-by-step guide that lets us reproduce a bug is often the single most important factor in determining whether we can fix a bug or not. When we aren’t able to reproduce the bug, it will often be resolved as “Not Repro”. Clearer and more detailed bug reports greatly improve our ability to understand the underlying issues and respond accordingly.
Screenshots & attachments
A good bug report may include screenshots (or even videos). For example, you can use screenshots to guide us through relatively complex steps or to highlight where we need to look to see the issue you’re reporting.
Also check out webcompat.com – Bug reporting for the internet
A great new service/initiative that makes it really easy to report a bug you have found with a browser or web site.
How It Works
- Report a bug for any website or browser.
- the webcompat team of volunteers diagnoses the bug.
- Then send a fix to the site owner or browser.