Compatibility/Guide

Working on Web Compatibility Issues

As said on Web Compatibility page:

A person should be able to use the Web from which ever device and browser they are using.

There are many ways we, Web users, can help make the Web a better place:

• Collect information about well-known sites in your own country.
• Report the issues in a useful way.
• Analyze the Web sites so that the bugs contain useful information.
• Contact Web sites owners (or developers) for fixing Web compatibility issues.

The work and the effort of the community is key to the success of the open Web. These efforts have to be considered in the constraints of the business requirements of each contacted Web site. We are not here to blame, we are here to make the Web open to anyone. The Web compatibility effort is driven by two projects mobile Web compatibility and desktop Web compatibility.

Collecting Information And Surveys

Once a mobile device has been introduced in a new country, some Web sites will exhibit issues of Web compatibility. Every country has popular Web sites which are related to their local market (for example well known press and magazines sites).

Steps to follow

1. Create a page with a list of top Web sites. See for example Brazil, India or Germany
2. Start small, grow it little by little
3. For each Web site, test the site with Firefox OS, Firefox Android (and Opera Mobile, IEMobile, Chrome Mobile, Android, etc.). You can get help by having a pre-generation of screenshots for your Web site list.
4. Note differences and open individual bugs for each individual issue (see below)

Reporting a Web compatibility issue

What?

1. Enter the Web site URI
2. You have not been able to use it with your Web browsers of choice
3. Check on other browsers. Are there any differences making the site unusable.

You can help!

This guide is focused on Mozilla browsers but you can also help other browser vendors. If you have an issue with Opera (Bug Wizard), Chrome (Bug), Safari (Bug) or Internet Explorer (Bug).

PS: We try to avoid to fix Web sites which are working badly everywhere. We focus first our energy on Web sites which are broken in one browser and not the others.

Requirements

You will need a Mozilla bugzilla account. If not create a new account.

Steps to follow

The person (volunteer or Mozilla engineer) will need to know which steps you have followed to reach the issue. The more details you give, the better chance the issue will be properly addressed. If, for example, one must log in to see the issue, it is important to say so.

1. Create a new bug in Bugzilla
   1. Describe the steps you have been doing for reaching the point where you have an issue: Example of steps
   2. Describe what is happening
   3. Describe what you were expecting
   4. Give information about your device and your browser
2. (Bonus) Test in one or more browsers to understand the differences: Example of tests in different browsers

Someone might ask further questions in the bug report to better understand the issue.

Do not forget: Be nice. It is our collective effort.

Analyzing for Web Compatibility Issues

There are many ways of analyzing a Web site for Web Compatibility issues. We could write an entire book with the types of issues and techniques used to find them.

Mozilla Bugzilla Process for Analysis

You might want help analyzing Mobile Web Compatibility bugs. A bug which has the status NEW or ASSIGNED are basically the same.

1. When analyzing the bug, take it (and change the bug to ASSIGNED).
2. Once you've discovered the type of issue affecting the site:
   1. document in a comment
   2. flag it with a whiteboard keyword for example [serversniff] if it's related to server side user agent detection. Jump to the full list.
3. If you do not plan to work further on the bug, such as contacting the Web site, Unassign yourself

You may use some tools and techniques for investigating bugs.

Finding The Right Contact on a Web site

For solving the issues, we often need to find the right person on the Web site. It is often the hardest part of the job, but it's where you can really make a difference. Some Web sites are written in a language that you are mastering. Some Web sites are in country where we do not have much context on how to contact the right person. You can help. The open Web is the work of everyone. Here is a concrete example. If you have more tips, share them here.

There is more than one strategy for finding a person related to a Web compatibility issue. Here are a few:

• Does the company have a developer relations department?
• Is there a support email address or Web form on the Web site?
• Is there an email address for the Communications department?
• Is there an email address for the Technical department?
• If the company has an organigram of their management, search for people who are CTO, Marketing, or Communications related, then check online if you can find them either on Twitter or Linkedin. But, be careful. If the person is obviously only using the account for personal stuff, do not bother them.
• Does the company have a Twitter account?
• Does the company have a Github, Bitbucket or Google code account?
• As a last resort, you may try through their Press relations address which is usually open.
• Call a phone number of the company, though you may be bounced around.
• You might want to check the WHOIS record for the domain name. In some rare cases, it is possible to find useful information about the owner of the site.

Before contacting, read the next section.

Negotiating with the Web site for fixing a Web compatibility issue

First of all, this is a negotiation process. People you will try to contact have their own set of constraints and that might be difficult for them to understand, fix the issue. So be nice.

• Never ever be aggressive with the persons you are trying to reach out. We want a better Web, not an angry Web ;).
• Never assume you are contacting the right person.
• Do not harass people with a lot of emails (even if they are nice to you). A good rule of thumb is to wait one week between contacts. Then a month for the third contact. If nothing has happened during the 5 weeks, give up.
• Never share publicly the emails or names of people in the bug report if they have not decided to reveal themselves. Sometimes people will be willing to help fix a Web site without necessarily telling their management. Exposing them would make their work more difficult.
• Invite people to participate to the bugzilla themselves.
• If someone doesn't want to open a bugzilla account but is willing to share his/her comments in the bug report, help them to publish it (but only if they agree).

There is no perfect email for contacting Web site, but if you think you are not necessarilyy contacting the right person it helps to write shorter emails. We created some templates in different languages. They are very simple, straight to the point and asking for better contact information. It is just an example. Some countries require more formalism, etc. Adjust depending on the local culture in your own language.

On twitter, it could be straightforward. For example

   @example Hi, would you know who I should contact 
   for Web site issues? 
   See https://bugzilla.mozilla.org/show_bug.cgi?id=<issue_number>

Bugzilla Conventions for Web Compatibility Issues

We are using a list of conventions in the Web Compatibility activity.

Mobile Web Compatibility Issues By Countries

Web Compatibility often requires to communicate with the Web site developer or owner in his/her own language. We try to keep a list of countries for people with specific language skills can get easily involved in the work.