Website Checking Tools » History » Revision 5
Revision 4 (Sarah Zaranek, 07/15/2022 02:28 PM) → Revision 5/6 (Peter Amstutz, 08/11/2022 07:00 PM)
h1. Website Checking Tools
h2. Development process
There are two branches, "main" and "develop"
The "main" one is the main site. When it is pushed, the site is automatically redeployed.
The "develop" goes to the "dev" version of the site. We push to this when
To avoid a confusing edit history, we want "develop" and "main" to always share the same history, with "develop" having additional changes being previewed prior to merging. _If we start merging "main" and "develop" back and forth we'll get spaghetti history and it'll be hard to keep track of which changes have been made, and where._
The process for making changes is:
# create a new branch off of main
## git checkout main
## git branch my-branch
## git checkout my-branch
# make changes and test locally on that branch
# check if "develop" is even with "main" (meaning, they should have the exact same commit)
## git show-ref main develop (the branches should all have the same commit hash)
## if "develop" is ahead of "main" then someone else is working on previewing/merging a change (they're on step 5), check in with them
# using "git rebase", apply your commits to the "develop" branch (this re-applies the changes you made in your branch, onto the develop branch)
## git checkout develop
## git rebase <my-branch>
# push "develop" and confirm that the dev site is displaying properly, ask other people to review it, etc
# fast-forward "main" to match "develop"
## git checkout main
## git merge --ff-only develop
h2. Responsiveness/mobile
* Firefox Responsive Design Mode (CTRL + SHIFT + M shortcut on linux)
* Resize the window to really small (mobile, or xs- in bootstrap, then increase a little to about 400-800 px when the medium viewport must trigger, or md I think in bootstrap)
h2. Accessibility
* WAVE - https://wave.webaim.org/
* Firefox - Right click anywhere on the screen and "Inspect Accessibility Properties"
* Accessi - https://www.accessi.org/
* pa11y.org - https://pa11y.org/
* For contrast, my favorite is squinting my eyes… similar to how you can do to simplify colors in a painting… I find that when the text color fades and almost disappears, that's normally because of bad contrast, and users with disabilities/diseases that cause blurred vision probably won't be comfortable reading it (I did that for Arvados.org and noticed some text that was hard to read, before testing with WAVE & accessi :joy: I just try never let anyone see me doing it) - https://www.sightsize.com/the-value-of-squinting/
* ORCA Linux screen reader - I find that these automated reports are useful for auditing, but for really confirm if a site is accessible, the best is always to ask a person with a disability to test it, or use a screen reader. Windows has a screen reader that's a lot better than ORCA.
h2. Performance
* Chrome Lighthouse - https://developer.chrome.com/blog/lighthouse-load-performance/
h2. Link Check
* W3C Link Checker - https://validator.w3.org/checklink
h2. Typos & Grammar
* WebStorm (it has a "Inspect" feature that uses a dictionary for typos, and a mix of custom language-rules & LanguageTools for Grammar). Not perfect, and I only run it when I have the code (I didn't use it for Arvados.org)
h2. SEO
* These two pages recommended by google, for schema.org tags - https://developers.google.com/search/docs/advanced/structured-data (e.g. https://validator.schema.org/#url=arvados.org)
h2. JS/CSS
* Firefox console, checking for warnings/errors.