Quality Recommendations for Apps & Websites

Why These Recommendations

Most quality problems on apps and websites are not exotic. They are the same preventable issues turning up again and again: text nobody can read over a photo, buttons that look like plain links, two competing page titles, a footer credit pasted in twice, a layout that falls apart on a phone. These recommendations collect the checks that catch those problems before your visitors do.

They are written for teams doing app development or website work of any size. None of them need special tools — most need only a browser, a phone, and the discipline to verify on the real page instead of assuming.

1. Accessibility — WCAG 2.2 AA

Accessibility is the foundation, not a final pass. If people cannot read the text, see the focus, or use the page with a keyboard, nothing else on the page matters. Build to WCAG 2.2 AA from the start: real contrast, real labels, and a page that works without a mouse.

Hold color contrast to at least 4.5:1 for body text and 3:1 for large text and UI components.
Give every image alt text that describes it, and mark purely decorative images as decorative.
Make sure the whole page works by keyboard alone, with a focus indicator that is always visible.
Put a skip link on every page so keyboard and screen-reader users can get straight to the content.
Give form fields real labels, with help text under the label that explains what to enter and why.
Never convey information by color alone — pair color with text, an icon, or a pattern.
Use headings, landmarks, and a page title that actually describe the page.

2. Headers & Content Structure

Headings are the page's outline — for visitors skimming, for search engines, and for screen readers navigating by heading. One clear H1, a hierarchy that never skips a level, and no repeated header wording keeps that outline honest and easy to scan.

Use exactly one H1 per page, and make it match what the page is about.
Keep header hierarchy in order — H1, then H2, then H3 — with no skipped levels.
Header words can't repeat: no two headers on a page use the same words.
Don't duplicate the page header with an in-body title saying the same thing.
Set FAQ questions and headers in bold text so they stand out as structure, not decoration.
Titles and labels should say what the thing actually is — never a bare, vague label.

3. Buttons & Links

People act on what they can recognize. A button that looks like a plain blue underlined link reads as text, not as an action — so buttons should look like buttons: filled, padded, clearly labeled, and consistent everywhere on the site.

Make buttons read as real buttons: a filled pill or block shape with contrasting text.
Buttons are never blue and never underlined — including the label text.
Write button labels in Title Case.
Give buttons clear spacing so they never touch each other.
Social media links are icons only, never text links.
Make link text descriptive — no bare "click here."

The footer is part of the product, and it is where sloppy duplication hides. One credit line, stated once. Vendor badges and privacy promises you haven't actually adopted don't belong there — a footer should say what is true, once, and stop.

Carry exactly ONE site credit: "Website by aCo Digital · Supported by aCo App," with the aCo logo, linking to aco.digital and app.aco.digital.
Check for duplicate "Designed by" or "Website by" lines anywhere on the page — one credit, never two.
Never add a Netlify badge (or any hosting badge) to a site.
Don't publish "we never sell your data/email" promises — privacy text must match the actual policy, not a slogan.

5. Layout & Mobile

Most visitors arrive on a phone. A page that scrolls sideways, squeezes text, or ships a sideways photo fails the majority of its audience. Design and verify at phone width first — 390px is a good working standard — and open every image before it goes on a page.

The page must fit phone width (390px) with no horizontal scrolling.
Where menus and filter rows are designed to scroll horizontally, they scroll in one row.
Text sizes stay readable on phone and desktop alike.
Images are the right way up, sharp, and verified by opening them — never chosen by filename.

Visitors should always know where they are on a site and how to get where they are going. Skip links get keyboard and screen-reader users past repeated menus, breadcrumbs show where a page sits, and a nav label that matches the page it opens keeps people oriented instead of second-guessing whether they landed in the right place.

Put a skip navigation link on every page so keyboard users can jump straight past the menu.
Add a skip-to-top / back-to-top link so long pages are easy to leave as well as enter.
Give pages breadcrumbs that show where the page sits in the site.
Make the page nav label and the page H1 match — people should never wonder if they landed on the right page.
Show an active style for the current page in the nav — aria-current plus a visual distinction, never color alone.

6. Analytics & Tracking

Analytics only helps if it is measuring the right property on the right pages. One tag per site, using that site's own Measurement ID — and confirm it is actually firing, because an installed tag that never sends data is worse than none: it looks like zero traffic.

Install the Google Analytics tag with the site's own Measurement ID, and verify it is firing.
Remove duplicate or leftover tags from other properties.

7. Voice & Accuracy

A site speaks for the organization, not for whoever happened to edit the page. Write in the site's own voice, publish only facts you can stand behind, and verify every name, date, and number against its source before it goes live.

Site copy is written in the site's own voice. For society and genealogy sites, that means a neutral, organization-wide voice — never one person's perspective.
Genealogy content states documented facts only — no guessing, no invented color.
Call visitors what the site calls them — guests, never customers, where that applies.
Verify names, dates, and numbers against the source before publishing.

ARIA

ARIA fills the gaps native HTML cannot — but only when it is accurate. Wrong ARIA is worse than none at all: a stale expanded state or a label pointing at an ID that doesn't exist tells screen-reader users things that are not true. Reach for a real HTML element first, and add ARIA only where HTML runs out.

Give icon-only buttons and links an aria-label that says what they do.
Mark decorative elements aria-hidden — and never leave them focusable while hidden.
Menu and disclosure buttons use aria-expanded, and it changes with state.
Mark the current page in nav with aria-current="page".
Check that every aria-labelledby and aria-describedby points at an ID that actually exists.
Never put role="button" (or a similar role) on elements that can't be used by keyboard.
Status messages and toasts use a live region so screen readers announce them.
Use ARIA only where native HTML can't do the job — a real button beats a div with a role.

Practical Testing — Do This, Look For This

Automated checkers catch only part of accessibility. The rest shows up when a person actually uses the page: tabbing through it, zooming in, shrinking the window, and submitting the form wrong on purpose. These are the hands-on passes to run on every page — do each one, and look for what it is meant to catch.

Keyboard walk: unplug the mouse and Tab through the whole page — every control reachable, focus always visible, nothing traps.
Check that the focus order follows the reading order on the page.
Make sure the focused element is never hidden behind a sticky header or banner (WCAG 2.2 — focus not obscured).
Run a screen reader pass — NVDA on Windows or VoiceOver on Mac/iPhone: the headings list makes sense, images announce their alt text, buttons say what they do.
Zoom to 200%, then 400%: nothing overlaps, no two-way scrolling, text doesn't get cut off.
Shrink the window to 320px wide: content reflows to one column and still works.
Measure touch targets: at least 24 × 24 CSS pixels (the WCAG 2.2 minimum), 44px preferred.
Anything you can drag must also work with a simple tap or click (WCAG 2.2 — dragging movements).
Submit forms empty and with errors: errors are named in text (not color alone), tied to the field, and focus moves to the error summary.
Keep contact and help options in the same place on every page (WCAG 2.2 — consistent help).
Never ask twice for information already given (WCAG 2.2 — redundant entry).
Sign-in works without a memory or puzzle test — offer an email link, a code, or a passkey (WCAG 2.2 — accessible authentication).
Turn on prefers-reduced-motion: animations stop or calm down.
Turn CSS off, or load on a slow connection: content order still makes sense and the page is usable.
Check one page with an automated tool — the aCo Accessibility Checker or WAVE — AND by hand: automated tools catch only part of it.

8. Before Anything Goes Live

Publishing is the step where careful work gets lost — an editor that rewrites your code, an autosave that never happened, a preview link that doesn't match production. Protect the work: back up first, edit in code view, and verify the change on the rendered page on the real domain.

Save a backup before editing anything live — a theme XML download or a copy of the file.
Edit in code/HTML view only on platforms that offer one; visual editors can silently break page code.
Save at least every 5 minutes on platforms without autosave, such as Blogger.
Verify every change in a real browser on the custom domain — deploy-preview subdomains are not proof.
Check staging first, then verify production after the deploy.

The Full Checklist

This is the complete Site QA Checklist, published in full. Run every item before a site or page is called done, and verify on the rendered live page (custom domain), in a real browser — never by fetched HTML alone. Prefer paper? The document version is the same checklist, formatted for print.

Download The Checklist