Browser Support

Scope: OIT
Type: Standard
Version: 2024

Goal

Streamline web development and testing using a browser agnostic stance focusing on web features over web browsers.

Ownership

Direct questions to the Owner: Seth A. Roby

Resources to comply with this standard should be directed via the Executive sponsor: TBD

Timeline & Enforcement

All sites should shift their support posture by the end of calendar year 2024.

Exception Process

If a particular site has more stringent requirements, the director can sign off on an exception.

Terminology

Background

  1. The Office of Information Technology (OIT) wants to guarantee that our web sites work well in a variety of browsers, because there is one web that works across browsers.
  2. We want to assure users that they can use their browser of choice with our properties. Historically we have done this by supporting the browsers with the largest userbases (currently Chrome, Safari, Edge, and Firefox), and verifying that our sites work with the current version and the previous one.
  3. However, browser update cycles are now so fast that tracking version numbers is no longer helpful; “current and one back” for Chrome is a one-month window; that’s comparable to many teams’ app deploy timelines.
  4. One alternative to tracking browser versions is to track browser features using Baseline, which tracks which features are supported by four “core browsers” which are the same ones we’ve long supported.

Requirements

Feature Focus

  1. Sites created by OIT MUST use the Baseline project to determine which browser features to use in production.
  2. If a feature is Widely available according to Baseline, you MAY use it.
  3. If a feature is Newly available or has Limited availability, it may be used only as a progressive enhancement. Use the feature only if that use will not harm browsers that don’t support it; you MAY NOT use these feature without such a fallback.
  4. This approach restricts usage of new features to nice-to-have additions rather than mission-critical requirements. But it means we don’t necessarily have to wait for every browser to support a feature before using it.

Browser Testing

  1. Teams MUST proactively test all sites in two or more of Baseline’s core browsers
    1. Teams SHOULD proactively test all sites regularly in mobile browsers as well as desktop browsers
  2. We aim to make our sites work in all browsers. The core content and functionality of a website should be available to any browser. That doesn’t mean the content will look exactly the same in every browser. It also doesn’t mean that every interaction will be identical or available to every browser. Some interactions may be implemented as progressive enhancements only available to newer browsers, provided the interaction isn’t part of the core functionality of the website.
  3. If a browser doesn’t yet support a specific feature, it almost certainly will in the future – Interop provides a list of features which browser makers have collectively agreed to prioritise. Teams SHOULD spend time ensuring that features are deployed as progressive enhancements so that lack of support isn’t a blocker, and browsers will catch up in time.

Access for all

  1. Underlying this policy are two foundational principles:
    1. Website content and core functionality should be accessible to everyone.
    2. It’s okay for websites to look different in different browsers.
  2. If content is unreadable in some browsers, that’s a bug that we SHALL fix. If content is displayed slightly differently in some browsers, we consider that to be a facet of the web, not a bug. This means that there will sometimes be subtle visual and functional differences from browser to browser. We deem this acceptable provided content and core functionality are unaffected.

See Also