18 Usability Guidelines and Website Design Standards

Strong usability is what turns a website from a brochure into a tool people actually use. Easy access, efficient interaction, content that answers the visitor’s real questions — these aren’t style preferences but well-studied design principles backed by decades of research from the Nielsen Norman Group, the Baymard Institute, the W3C’s Web Accessibility Initiative, and the U.S. Department of Health and Human Services’ Research-Based Web Design & Usability Guidelines.

The 18 guidelines below distill that body of research into a checklist any designer, developer, content strategist, or product manager can apply to their own site, updated for 2026 expectations: mobile-first design, WCAG 2.2 Level AA accessibility, the DOJ’s April 2024 Title II final rule, the European Accessibility Act, and the Core Web Vitals performance standard.

Why these guidelines matter

Whether you’re building a new site or making an existing one more user-friendly, applying research-based usability guidelines from the start saves you from the much more expensive work of fixing problems after launch. Beyond the user benefit, accessibility specifically is now a legal requirement for many organizations: the U.S. DOJ’s April 2024 Title II final rule made WCAG 2.1 Level AA the standard for state and local government services, with the April 2026 Interim Final Rule setting deadlines of April 26, 2027 (jurisdictions of 50,000+) and April 26, 2028 (smaller jurisdictions). The European Accessibility Act entered enforcement on June 28, 2025.

The guidelines below incorporate those legal expectations and the more recent UX research from NN/g, Baymard, WebAIM, and Google’s Core Web Vitals program — modern guidance for sites that ship in 2026.

18 usability guidelines

1. Design with users, not for them

The single most reliable predictor of a usable site is whether real users were involved in shaping it. Test with real users early and often — five users in a moderated session find about 85% of a page’s usability problems (NN/g, Nielsen, 2000, replicated repeatedly since). Define usability goals up front (task completion rate, time-on-task, error rate, satisfaction score) and measure against them at each iteration. Modern remote testing platforms (UserTesting, Maze, Lookback, PlaybookUX) make this affordable for teams of any size. Avoid the pitfall of designing only from internal stakeholder opinion.

2. Optimize the overall user experience

Friction kills conversion. Avoid intrusive popups (Google’s 2017 mobile-interstitial penalty is still in effect), maintain a consistent visual hierarchy and interaction language across the site, and signal load times for any operation longer than 2-3 seconds. Make important pages easy to print or save (especially policy, pricing, and reference content). Provide a clearly accessible help mechanism — WCAG 2.2 SC 3.2.6 Consistent Help requires that help mechanisms appear in the same relative order on every page where they exist.

3. Accessibility

Build to WCAG 2.2 Level AA as the technical baseline. WCAG 2.2 added nine new criteria over 2.1, including 2.4.11 Focus Not Obscured, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication. Provide alt text for meaningful images, captions and transcripts for video, descriptive form labels, keyboard-operable controls, and color contrast meeting 4.5:1 for normal text and 3:1 for large text and UI components. Section 504 still applies to federally funded organizations; private businesses are exposed under ADA Title III; public-sector organizations are covered by the DOJ’s 2024 Title II rule. Test with axe DevTools, WAVE, or Microsoft Accessibility Insights for automated scans, plus manual keyboard and screen-reader checks.

4. Hardware and software (mobile-first design)

The single most important shift since this guidance was originally written: most web traffic is now mobile. Design mobile-first, then progressively enhance for tablet and desktop. Common viewport widths to test: 360px (small phone), 390px (iPhone), 768px (tablet), 1280px (laptop), 1920px (desktop). Browser support: Chrome, Safari, Firefox, Edge (Internet Explorer was retired June 15, 2022 — drop legacy IE shims unless you have a specific enterprise requirement). Operating system mix in 2026 is dominated by Windows 10/11, macOS, iOS, and Android; legacy Windows versions like XP, 7, and 8 are no longer worth designing for.

5. The home page

The home page is still the highest-traffic page on most sites and a major scanning surface. Within seconds, visitors should be able to tell what the site offers, who it’s for, and what to do next. Lead with a clear value proposition, surface the primary actions, and make navigation immediately apparent. Avoid wall-of-text or wall-of-images openings. If something has changed (a new pricing page, a discontinued product, a relocated feature), surface that change near the top. NN/g eyetracking research consistently shows F-shaped scanning patterns on content pages and Z-shaped on landing pages — design with that scanning behavior in mind.

6. Page layout

Use a clear visual hierarchy to guide the eye to the most important content first. Place primary calls to action above the fold on key templates. Group comparable information together (don’t make users navigate back and forth to compare). Use whitespace deliberately — too little produces clutter, too much wastes attention. Align elements consistently using a grid; modern design tools (Figma auto-layout, CSS Grid, CSS Flexbox) make precise alignment cheap. Don’t use scroll stoppers (false bottoms that look like the end of the page).

7. Navigation

Use consistent, predictable navigation across all pages — WCAG SC 3.2.3 Consistent Navigation requires it. Make labels self-explanatory; users shouldn’t have to click to understand where a link leads. Breadcrumbs are now standard for most large sites — they help orientation, provide secondary navigation, and improve SEO via structured data. Provide a clearly visible search box on every page. Make sure the browser’s back button works as expected; SPAs should manage history state correctly.

8. Scrolling and reflow

Eliminate horizontal scrolling on standard layouts — WCAG SC 1.4.10 Reflow requires content to reflow into a single column at 320 CSS pixels without horizontal scrolling, except for content that genuinely needs two-dimensional layout (maps, complex tables, code blocks). Long scroll pages are fine on mobile and content sites; pagination is better for results lists, search results, and reference content where direct linking matters. Implement smooth scrolling and skip-to-content links for keyboard users.

9. Headings, titles, and labels

Use one H1 per page that describes the topic. Nest H2/H3/H4 in logical order — don’t skip levels for visual styling. Make headings descriptive enough to work as a table of contents; WCAG SC 2.4.6 Headings and Labels requires headings to describe topic or purpose. Make labels (form fields, buttons, controls) specific and unambiguous. “Submit” on a contact form is fine; “Submit” on a refund request is too vague.

10. Links

Write descriptive link text that works out of context. WCAG SC 2.4.4 Link Purpose requires that link purpose be determinable from the link text plus its surrounding context — “click here” and “read more” fail this. Indicate when links lead to non-HTML resources (PDFs, downloads, external sites). Test links regularly to catch breakage; broken-link scanners (Sitebulb, Screaming Frog, Ahrefs) should run on a schedule. Differentiate visited and unvisited links visually for content sites where users may be retracing steps.

11. Text appearance and typography

Use a body font size of at least 16px / 1rem in 2026 — the older 12pt advice is too small for modern displays and reading distances. Maintain contrast ratios that meet WCAG SC 1.4.3 Contrast (Minimum): 4.5:1 for normal text, 3:1 for large text (18pt or 14pt bold and above) and UI components. Ensure text scales to 200% without breaking layout (SC 1.4.4 Resize Text) and respects user-defined text spacing (SC 1.4.12 Text Spacing). Avoid all-caps blocks of text — they’re harder to read and screen readers may treat them as initialisms. Use bold and italic sparingly for emphasis only.

12. Lists

Use lists where information is parallel, scannable, and not deeply hierarchical. Lead with the most important item — readers often only scan the top of the list. Capitalize the first word of each item; punctuate consistently (either every item ends with a period or none do). Use ordered lists for sequences and unordered lists for non-sequenced items. For long lists, consider grouping or filtering.

13. Forms and screen-based controls

Forms are where most usability fails. Label every field with persistent visible text — never use placeholder text as the only label (it disappears on input and often fails contrast). Use HTML5 input types (type="email", type="tel", type="date") and the autocomplete attribute (WCAG SC 1.3.5 Identify Input Purpose) so password managers and assistive tech can fill fields automatically. Auto-focus the first field and support tab order. WCAG SC 3.3.7 Redundant Entry (new in WCAG 2.2) requires that previously entered information be auto-populated or available for selection rather than re-entered.

14. Graphics, images, and multimedia

Optimize images aggressively — large unoptimized media is a major Core Web Vitals failure. Use modern formats (WebP, AVIF) with fallbacks; serve responsive images with the srcset attribute. Provide descriptive alt text for meaningful images and empty alt (alt="") for decorative ones. Caption all video (WCAG SC 1.2.2) and provide audio descriptions or transcripts for video content (SC 1.2.3, 1.2.5). Avoid auto-playing audio (SC 1.4.2 Audio Control) and content that flashes more than three times per second (SC 2.3.1 Three Flashes or Below Threshold) — the latter can trigger seizures in users with photosensitive epilepsy.

15. Writing web content

Write at a reading level your audience can scan. U.S. grade 8-9 is a reasonable target for general-public content; technical or specialist content can sit higher. Use plain language, active voice, and short sentences. Define jargon on first use; avoid undefined acronyms. Prefer concrete examples to abstract claims. Use Hemingway Editor or Readable to spot-check.

16. Content organization

Organize content around user tasks, not internal org structure. Surface the most important content above the fold; secondary content should be accessible via navigation, search, or in-page anchors. Don’t repeat the same content on every page — repeat the navigation, not the body. Provide multiple entry paths to important content (WCAG SC 2.4.5 Multiple Ways): site search, structured navigation, sitemap, breadcrumbs, related-content blocks. Consider how users with different needs (audio, visual, cognitive) will access the same information.

17. Search

Site search is the primary navigation tool for many users — make it accessible from every page. Modern site-search options range from native CMS search (often weak) through Algolia, Elastic, Meilisearch, Typesense, and platform-built-in search like Shopify or WordPress with custom indexing. Support typo tolerance, synonyms, and related-term suggestions. Show recent or popular searches, particularly on mobile. Surface zero-results states with helpful suggestions rather than dead ends.

18. Usability testing

Test continuously, not just before launch. Standard methods:

• Moderated user testing (5-8 users per round) for deep insights on specific tasks. NN/g, Maze Pro, UserTesting, Lookback are typical platforms.
• Unmoderated remote testing for scale and speed. UserTesting, Maze, PlaybookUX, Userlytics.
• Analytics (GA4, Plausible, Fathom, Mixpanel, Amplitude) for quantitative behavior.
• Session replay (Hotjar, FullStory, LogRocket, Mouseflow) for actual interaction patterns.
• Surveys and feedback widgets (Hotjar, Sprig, Maze) for qualitative signal.
• Accessibility testing (axe DevTools, WAVE, Microsoft Accessibility Insights, manual screen-reader testing) — automated tools catch about 30-40% of WCAG issues, so manual testing is mandatory.
• Performance monitoring against Core Web Vitals (LCP < 2.5s, CLS < 0.1, INP < 200ms) using Lighthouse, PageSpeed Insights, or real-user monitoring.

Run a smaller round of testing every quarter rather than waiting for a major release; small problems caught early are cheap, accumulated problems caught late are expensive.

Frequently asked questions

Where do these guidelines come from?

The original framework comes from the U.S. Department of Health and Human Services’ Research-Based Web Design & Usability Guidelines. The guidelines above incorporate that foundation plus more recent UX research from the Nielsen Norman Group, the Baymard Institute, WebAIM, the W3C’s Web Accessibility Initiative (WCAG 2.2), and the Web Vitals program from Google.

How do these guidelines relate to WCAG?

Several of the guidelines map directly to specific WCAG 2.2 success criteria — accessibility, navigation, headings, links, forms, text appearance, and multimedia in particular. WCAG sets the legal baseline for accessibility; the broader usability guidelines extend beyond accessibility into general user experience.

How often should I audit my site against these guidelines?

Run a full guidelines audit at least annually, with rolling smaller checks each quarter. Major changes (a redesign, a new template family, a CMS migration) should trigger a fresh audit. Tools that help with continuous audit: DYNO Mapper’s accessibility testing, axe-core in CI, Lighthouse CI, Sitebulb, and Screaming Frog.

Are any of these guidelines optional?

The accessibility guidelines (especially #3, plus the WCAG-related elements within #7, #8, #9, #10, #11, #13, #14, #15, #16) are increasingly non-optional under DOJ Title II 2024 (public sector), Section 504 (federally funded), the EAA (EU market), and ADA Title III (private accommodations). The others are strong recommendations rather than legal requirements, but skipping them costs measurably in conversion, retention, and SEO.

How do these guidelines apply to mobile?

All of them apply, often more strictly. Mobile imposes harder constraints on viewport size, touch targets (WCAG SC 2.5.8 minimum 24×24 px, 44×44 px recommended), connection bandwidth, and attention. Design mobile-first, then progressively enhance — the reverse of the desktop-first approach the original 2006 guidelines assumed.

The bottom line

Usability isn’t a feature you bolt on after launch; it’s the structural quality that makes everything else work. The 18 guidelines above are the well-validated baseline — apply them upstream during design, validate them with real users at each iteration, and audit them on a recurring schedule. Sites that take this seriously rank better, convert better, and weather the legal and regulatory environment that accessibility has become without scrambling at the last minute.