Web App Audit Checklist

This checklist is a starting point for web app audits. It’s a living document, and will be updated as we learn more.

App Level

Do all user interactions pass WCAG 2.0 and WCAG 2.1 accessibility requirements?
A11y Review - From the a11y Project
- No-JS alternatives
- High Color Contrast Ratio (UX)
- Color Blindness
- Screen Reader Tests
- Keyboard only testing

Audit Performance and Scalability

Does the app measure these critical core web vitals in production?
Does the app pass critical core web vitals?
- Includes Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS).
- Thresholds can be found in a different wiki page, to be written
Do all API requests pass the expected latency threshold?
- API request latency can be found in a different wiki page, to be written
Are all data partitions working as intended? Do we need to review these partitions?
Are all data clustering working as intended?
Are there performance issues with shared DBs?

i18n Support

Do we need to add new terms in our i18n dictionary?

Testing Level

Do we have adequate testing coverage?
- Code coverage should not be the only metric, so we should double check our BDD tests and see if we have gaps

Package Level

Audit package dependencies: npm audit
nginx Audit - Are we on LTS?
Node Audit - Are we on LTS? (same with npm)

How to upgrade npm packages

Run yarn outdated. You will get a table of outdated packages. It will look like the following:

Package           Current Wanted Latest Package Type    URL
babel-jest        24.9.0  24.9.0 25.1.0 devDependencies https://github.com/facebook/jest#readme
normalizr         3.4.1   3.4.1  3.5.0  dependencies    https://github.com/paularmstrong/normalizr
react-dates       21.5.0  21.5.1 21.5.1 dependencies    https://github.com/airbnb/react-dates

npm uses semantic versioning, with a few exceptions.

The first number is the MAJOR version. The next is the MINOR version. Last digit is the PATCH version.

Patch Update

In our example table above, react-dates has a patch version update. 21.5.0 -> 21.5.1 The last digit changed from 0 to 1. That means the version is backwards compatible. Usually this means the package has bug fixes.

You can safely update the package.json with this package without doing any checks.

Minor Update

In our example table above, normalizr has a minor version update. 3.4.1 -> 3.5.0 The second digit changed from 4 to 5. That means the version should be backwards compatible. Usually this means the package has features added.

You can sometimes safely update the package.json with this package. Use your intuition if you need to check the pacakage in the app. For example, if the package type is a dev dependency, most likely you don’t have to make changes. The example package normalizr would fall under this case, and you can safely upgrade.

If there’s a new API or function worth exploring, make some changes and see how they work, if they apply to our application.

Major Update

In our example table above, babel-jest has a major version update. 24.9.0 -> 25.1.0 The first digit changed from 24 to 25. That means the version is not backwards compatible. Usually this means the package API has changed. In some cases, it may be because they have dropped support for an old version of Node. YMMV

You can never safely update the package.json with this package. Do the following:

Check the CHANGELOG.md or releases Github page. Figure out what the change is
If there are API changes, read up on what the changes are. If they are fundamental and big, do not add. Make a task ticket to upgrade.
- Sometimes the library might be popular. They may have a blog post on this. (e.g. Storybook, Apollo, React, and Styled-Components)
If it’s for dropped support for an older version of Node, go ahead and upgrade
For all other changes, upgrade locally, then see if anything in the App breaks. Also check Storybook and tests to see if anything breaks.

Be wary of major changes. When in doubt, as a teammate.