Browse all articles

Simple Tips for Vendors When Reviewing Terms

Topics:   Privacy Program

The technical details of how privacy terms are shared matter. This post shows some easily avoidable issues.

Bill Fitzgerald | January 3, 2016

This post is the result of many conversations over the last several years with Jeff Graham. It highlights some things that we have seen in our work on privacy and open educational resources. This post focuses on privacy, but the general lesson -- that bad markup gets in the way of good content -- holds true in both the OER and privacy spaces.

When looking at privacy policies and terms of service, the most important element is the content of the policy. However, these policies are generally delivered over the Web, so it's important to look at how the pages containing these policies perform on the Web. Toward that end, here are four simple things that vendors should be doing to ensure that their policies are as accessible as possible to as many people as possible, with as few barriers as possible.

  • View the source. In a Web browser, use the "view source" option. Does the text of your policy appear in the "main content" area of your page or in some semantic equivalent? Are you using h1-h6 tags appropriately? These are simple things to fix or do right.
  • Google your privacy policy and terms of service. First, use the string "privacy policy OR terms of service [your_product_name]". See what comes up. Then, use the more focused "privacy policy OR terms of service" -- in this search, be sure to omit the initial "www" so that your search picks up any subdomains.
  • Use an automated tool (such as PhantomJS) to capture screenshots of your policies. If PhantomJS has issues grabbing a screenshot of your page, it's a sign that you have issues with the markup on your page.
  • Use a screen reader to read your page. Listen to how or whether it works. Where we have observed issues with a page failing to behave in a screen reader, it's frequently due to faulty markup or the page being loaded dynamically via JavaScript.

To people working on the Web or in software development, these checks probably sound rudimentary -- and they are. They are the technical equivalent of being able to tie your shoes or walking and chewing gum at the same time.

In our research and analysis of privacy policies, we have seen the following issues repeated in many places; some of these issues are present on the sites of large companies. Also worth noting: This is a short list, highlighting only the most basic issues:

  • Pages where the policies are all wrapped in a form tag. For readers unfamiliar with HTML, the form tag is used to create forms to collect data.
  • Pages where, according to the markup, the policies are part of the footer.
  • Pages where, according to character count, the actual policies only account for 3 percent of the content on the page, with the other 97 percent being markup and scripts.
  • Sites where Google couldn't pick up the text of the policy and was only able to index the script that is supposed to load it.

We are not going to be naming names or pointing fingers -- at least not yet, and hopefully never. These issues are easy to fix and require skills that can be found in a technically savvy middle schooler. Vendors can and should be doing these reviews on their own. The fix for these issues is simple: Use standard, semantically accurate markup for your policies.

We hear a lot of talk in the privacy world about how privacy concerns could stifle innovation -- that's a separate conversation that will almost certainly be the topic of a different post, but it's also relevant here. When the people claiming to be the innovators have basic, demonstrable problems mastering HTML, it doesn't speak well to their ability to solve more complex issues.

Image credit: Gerd Altman, released under a CC0 license