Accessibility Basics for Personal Sites: Simple WCAG Checks

An accessible website is one that people with disabilities can use: people who are blind and use screen readers, people with low vision who zoom in, people who cannot use a mouse, people who are Deaf or hard of hearing, and people with cognitive or learning disabilities. On a personal site, that might be a recruiter, a client or a friend.

The W3C's Web Accessibility Initiative (WAI) points out that accessibility also helps people without disabilities, including people on small screens, people with temporary injuries such as a broken arm, people in bright sunlight or places where they cannot play audio, and people on slow connections. Most fixes are small, and on a personal site you control nearly all of them. This guide covers the standard, the habits that matter most and a quick self-check.

WCAG in brief

The Web Content Accessibility Guidelines (WCAG) are the international standard for web accessibility, developed by the W3C. According to WAI:

• WCAG 2.2 was published on October 5, 2023, and an update was published on December 12, 2024.
• WCAG 2.2 has 13 guidelines organized under four principles: perceivable, operable, understandable and robust.
• Each guideline has testable success criteria at three levels: A, AA and AAA.
• The versions are backward compatible, so content that meets WCAG 2.2 also meets 2.1 and 2.0. W3C encourages using the latest version.

You do not need to read the full standard to make a personal site much better. The habits below map to specific WCAG success criteria, noted in parentheses. Legal requirements for websites vary by country and situation, and WAI maintains an overview of laws and policies; this guide is practical guidance, not legal advice.

Start with structure: titles, headings and language

Page titles. WCAG requires that web pages have titles that describe their topic or purpose (2.4.2, Level A). WAI's writing tips suggest a short title that distinguishes each page from the others, with the unique part first, such as "Contact - Sam Lee."

Headings. Headings and labels should describe topic or purpose (2.4.6, Level AA). WAI notes that screen reader users often use headings to navigate a page, and that making text bigger or bold is not enough; headings need to be marked as headings. In most site builders, that means using the editor's heading styles rather than just enlarging text.

Language. The default language of each page should be identifiable by software (3.1.1, Level A), so screen readers pronounce words correctly. If your tool has a site language setting, check that it matches the language you write in.

Images, video and audio

WCAG requires a text alternative for non-text content such as images (1.1.1, Level A). WAI's alt text decision tree gives practical rules:

• If an image conveys meaning, write a brief description of what it conveys.
• If an image is a link or button, describe where it goes or what it does, not what it looks like.
• If an image contains text that appears nowhere else, include that text.
• If an image is purely decorative, use an empty alt attribute so screen readers skip it. If your builder lets you mark an image as decorative, use that option.
• If an image is a chart or something complex, put the information in the page text as well.

For example, on a hypothetical photographer's site, "Bride and groom laughing under an oak tree at dusk" helps far more than "IMG_4521" or "photo."

For video, provide captions for prerecorded audio content (1.2.2, Level A). For audio-only content such as a podcast, WAI recommends a transcript.

Color and text that people can read

WCAG's minimum contrast requirement (1.4.3, Level AA) is a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text, which WCAG defines as at least 18 point, or 14 point bold. Light gray text on a white background is an easy way to fall short. A contrast checker tool computes the ratio from two color codes.

Two related rules:

• Do not rely on color alone. WAI's design tips suggest adding another cue, such as an asterisk on required form fields, instead of only coloring them red.
• Let text grow. Text should be resizable up to 200 percent without losing content or functionality (1.4.4, Level AA). Try it by zooming your browser.

Links, buttons, keyboards and forms

Link text. The purpose of each link should be clear from its text, or from its text together with its context (2.4.4, Level A). WAI advises against vague link text like "click here" or "read more." Write "See my packaging projects" instead.

Keyboard access. All functionality should work with a keyboard (2.1.1, Level A), and the keyboard focus indicator should be visible (2.4.7, Level AA). If you cannot see where you are when pressing Tab, keyboard users cannot either.

Target size. WCAG 2.2 added a requirement that pointer targets such as buttons and icons be at least 24 by 24 CSS pixels, with some exceptions, including enough spacing around smaller targets (2.5.8, Level AA). Small social icons packed tightly together are worth checking.

Forms. Provide labels or instructions when content requires user input (3.3.2, Level A). On a contact form, every field needs a visible label, not just placeholder text that disappears when you start typing.

A 15-minute self-check

WAI's Easy Checks are a first review that anyone can do. WAI cautions that they cover only a few issues: a page could seem to pass them and still have significant barriers. They are still a good habit after every update.

1. Read the browser tab on each page. Is the title unique and descriptive?
2. Press Tab repeatedly from the top of the page. Can you reach every link and button, and always see where you are?
3. Zoom to 200 percent. Does everything still fit and work?
4. Check each meaningful image for alt text, using your builder's image settings.
5. Run your text and background colors through a contrast checker.
6. Scan your headings. Do they form a sensible outline of the page?
7. Try your contact form using only the keyboard.

Fix what you find, and repeat the check whenever you change templates. Our guide, Building a Personal Website Without Code: A Step-by-Step Plan, covers how to build these habits in from the start.

Key takeaways

• WCAG 2.2 is the latest W3C version, with success criteria at levels A, AA and AAA; it is backward compatible with 2.1 and 2.0.
• Use descriptive page titles, real headings and a correct page language setting.
• Write alt text that conveys purpose, mark decorative images as decorative and caption videos.
• Aim for 4.5:1 text contrast (3:1 for large text), do not rely on color alone and let text zoom to 200 percent.
• Use descriptive link text, test with a keyboard and label every form field.

Sources

• W3C Web Accessibility Initiative, WCAG 2 Overview
• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation (December 12, 2024)
• W3C Web Accessibility Initiative, Introduction to Web Accessibility
• W3C Web Accessibility Initiative, Writing for Web Accessibility: Tips for Getting Started
• W3C Web Accessibility Initiative, Designing for Web Accessibility: Tips for Getting Started
• W3C Web Accessibility Initiative, An alt Decision Tree
• W3C Web Accessibility Initiative, Easy Checks: A First Review of Web Accessibility
• W3C Web Accessibility Initiative, Web Accessibility Laws and Policies