filing bugs

Fireox Microsoft Edge  chrome  Safari Opera

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)

Filing bugs:

Firefox

Example bug: expose heading level in acc layer based on outline depth not heading numeric value

Use the Firefox bugzilla, you need to register to file. Read the bug writing guidelines

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.

Edge

Edge HTML Issue Tracker, you need to sign up for a Microsoft account (if you don’t have one) to file.  Read the Bug reporting guidelines

Advice from David Storey:

If you can:

  1. Also include a reduction that just shows issue.
  2. 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.

Safari

Example bug: HTML indeterminate IDL attribute not mapped to checkbox value=2

Use the Webkit bugzilla, there is an accessibility related category, you need to sign up for a webkit bugzilla account to file.  Read the Bug writing guidelines

Chrome

You need a Google account to file bugs.

Example bug: hr element not exposed with a separator role

Opera

Use the Opera bug report wizard (though note that, once filed, you won’t be able to check back on the bug’s status…but if it gets fixed, it’ll appear in the relevant Opera release notes).

Writing bugs

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

Title

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”

Description

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

  1. Report a bug for any website or browser.
  2. the webcompat team of volunteers diagnoses the bug.
  3. Then send a fix to the site owner or browser.
Categories: Development

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.