Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

USWDS - Feature: clarify browser support #5888

Open
2 tasks done
anselmbradford opened this issue Apr 25, 2024 · 0 comments
Open
2 tasks done

USWDS - Feature: clarify browser support #5888

anselmbradford opened this issue Apr 25, 2024 · 0 comments
Assignees
Labels
Needs: Discussion We need to discuss an approach to this issue Type: Feature Request New functionality

Comments

@anselmbradford
Copy link

anselmbradford commented Apr 25, 2024

Is your feature request related to a problem? Please describe.

The browser support section says:

we officially support any browser above 2% usage as observed by analytics.usa.gov

The 2% rule comes from some old UK gov source documents, that state “… You will still need to support Internet Explorer 11 if your analytics data shows at least 2% of your users arriving at the service’s start page are using it.” Implying that the source of truth for the support should ultimately lie with the site’s visitor analytics data.

The USWDS says the support is set against what is shown on analytics.usa.gov. I have some questions with this:

  • analytics.usa.gov shows browser metrics for the past 30 days. This seems like a relatively narrow slice of time to base support upon. An aggregate amount from quarterly, semi-annual, or annual traffic seems like it would be more appropriate. Thoughts?

  • analytics.usa.gov appears to combine Safari (iOS) and Safari (desktop). I believe Safari (In app) would only be a WebView from within an iOS app, and would not include the iOS Safari browser. With the 2% cutoff, Firefox is very close to falling off, but in regard to desktop users exclusively I would imagine Firefox is a much higher percentage.

  • The USWDS code uses browserslist, which specifies greater than 2%. As far as I can see this is 2% of worldwide traffic via the caniuse-lite database, and is not attached to analytics.usa.gov.

Describe the solution you'd like

Clarify how the USWDS determines browser support. Over what time period are browser metrics used and what does support mean for USWDS and projects that may use it? How are desktop and mobile users differentiated in regard to the 2% rule? I think it would make the most sense to provide guidance on basing support on actual visitors and providing a process by which implementators could report back support levels that are incongruent with their visitor data. (E.g. extreme example, but if one agency had 90% IE users for some reason, USWDS may still not support it, but it would be good to know that is happening, and if other agencies trended this way, maybe it WOULD shift USWDS support tables). Some instructions on incorporating real site metrics can be found via https://github.com/browserslist/browserslist-ga-export?tab=readme-ov-file#google-analytics-4

Describe alternatives you've considered

No response

Additional context

The current browserslist config string provides ~78.8% coverage globally, and ~61% for the USA (see https://browsersl.ist/#q=%3E+2%25%2C+last+2+versions%2C+IE+11%2C+not+dead&region=US). The browserslist defaults cover ~87.4 % globally and ~79.2 % for the USA (see https://browsersl.ist/#q=defaults&region=US). You may want to consider whether the support string should be adjusted to increase USA coverage (according to caniuse-lite).

The UK gov purports to publish their support metrics in January and June, according to https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices (though that page is two years out of date 😬). They also aim for targeting 95% of the most popular browsers. For USWDS, it may help to clarify what time period to use for browser metrics.

Code of Conduct

@anselmbradford anselmbradford added the Type: Feature Request New functionality label Apr 25, 2024
@github-actions github-actions bot added the Status: Triage We're triaging this issue and grooming if necessary label Apr 25, 2024
@brunerae brunerae added Needs: Discussion We need to discuss an approach to this issue and removed Status: Triage We're triaging this issue and grooming if necessary labels May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Discussion We need to discuss an approach to this issue Type: Feature Request New functionality
Projects
Status: No status
Development

No branches or pull requests

3 participants