Website Accessibility — Building a Personal Site More People Can Actually Use Written by Adam Muiz 10 Aug 2026 Updated: 10 Aug 2026 8 min read When I first built a personal website, accessibility felt like a specialist subject I could postpone until the design was finished. The page looked clear on my laptop, so I assumed it worked for everyone. That assumption is a little like arranging a room while standing in one spot: the furniture may look tidy, but we do not know whether someone can reach the door, read the labels, or move through the room without obstacles. Website accessibility is the practice of making content and controls usable by people with different abilities, devices, and circumstances. It includes visitors who use a screen reader, navigate by keyboard, have low vision, cannot distinguish certain colors, experience motion sensitivity, or are temporarily using one hand. It also helps someone reading in bright sunlight, browsing on a slow connection, or trying to understand an unfamiliar language. A personal site does not need a corporate compliance department to improve. It needs thoughtful foundations and a repeatable way to notice barriers. Accessibility Is a Quality Attribute, Not a Final Coat of Paint The Web Content Accessibility Guidelines, usually called WCAG, organize accessibility around four principles: content should be perceivable, operable, understandable, and robust. These words sound formal, but they describe ordinary questions. Can a visitor perceive the information without relying on one sense? Can they operate every control? Is the interface predictable? Can assistive technology interpret it reliably? Thinking this way changes accessibility from a checklist into an engineering habit. A missing form label is an interface with no dependable name. Low contrast can make information disappear. A menu that only opens on hover is a locked cabinet for someone who does not use a pointer. The goal is not to make every experience identical. The goal is to preserve access to the same information and actions. Start with Semantic HTML Native HTML elements carry meaning and behavior before CSS or JavaScript runs. A real <button> can receive keyboard focus, responds to expected keys, and exposes its role to assistive technology. A clickable <div> does none of that automatically. Rebuilding those features with ARIA and event handlers is possible, but it is like assembling a chair from spare metal when a sturdy chair is already available. Use headings in a logical hierarchy, landmarks such as <main> and <nav>, lists for actual collections, links for navigation, and buttons for actions. Give every page a descriptive <title> and set the document language. A compact article layout can begin with ordinary, meaningful markup: <html lang="en"> <head> <title>Website Accessibility - A Practical Guide</title> </head> <body> <header> <nav aria-label="Primary">...</nav> </header> <main id="main-content"> <article>...</article> </main> </body> </html> ARIA is useful when native HTML cannot express a component, but it should not be the first tool pulled from the drawer. Incorrect ARIA can announce the wrong state or hide useful information. Prefer native semantics, then add ARIA only where it supplies a missing name, relationship, or state. Make Keyboard Navigation Visible and Complete Unplugging the mouse is one of the fastest accessibility tests available. Press Tab from the address bar and follow the focus indicator. You should be able to reach every interactive element in a sensible order, activate links and buttons with the keyboard, close dialogs with Escape, and avoid becoming trapped inside a widget. Do not remove the browser outline unless you replace it with an equally visible focus style. The outline is like a cursor on a map: without it, keyboard users know they are moving but cannot see where they have arrived. :focus-visible lets a site provide a strong indicator when keyboard-style focus is relevant without adding a ring after every pointer click. :focus-visible { outline: 3px solid #0b6bcb; outline-offset: 3px; } .skip-link { position: absolute; left: -9999px; } .skip-link:focus { left: 1rem; top: 1rem; z-index: 1000; } A skip link should be the first focusable element and point to the main content. It saves keyboard and screen-reader users from crossing the entire header on every page. Also keep the DOM order aligned with the visual order. CSS can move cards around, but the keyboard still follows the document, which can otherwise create a confusing journey. Use Color as Support, Never as the Only Message Color contrast affects far more people than those with a diagnosed vision condition. Thin gray text can become unreadable on a low-quality display or outdoors. As a practical WCAG target, normal text should generally reach a contrast ratio of at least 4.5:1, while large text needs at least 3:1. Tools can measure the ratio, but real-device testing still matters because weight, size, and surrounding colors affect perception. Color must not carry meaning alone. If a form marks invalid fields only with a red border, some visitors will miss the state. Add a clear text message, an icon with an accessible name when appropriate, and programmatic error association. The same rule applies to charts, status badges, and links embedded in paragraphs. Underlines are often the simplest dependable signal that text is clickable. Write Useful Alternatives for Images and Media Alternative text should communicate the purpose of an image in its context, not inventory every pixel. A portrait linked to an author profile might use the author's name. A screenshot in a tutorial should describe the setting or result the reader needs to find. A decorative shape that adds no information should use an empty alt attribute so a screen reader can pass over it rather than announcing a meaningless filename. Complex diagrams may need a short alt plus a longer explanation in nearby text. Videos need captions for spoken content and meaningful sound; audio-first material benefits from a transcript. These alternatives are not secondary leftovers. They are parallel routes to the same destination, like stairs and a ramp designed into the same entrance rather than attached behind the building later. Design Forms That Explain Themselves Every input needs a visible label associated through for and id, or an equivalent native relationship. Placeholder text is not a label: it disappears while typing, often has weak contrast, and forces people to remember the prompt. Instructions should appear before they are needed, especially for password rules, date formats, or required fields. When validation fails, identify the field, explain the problem in plain language, and suggest how to correct it. Move focus carefully to an error summary for a long form, while linking each summary item back to its field. Avoid messages such as “Invalid value” when “Enter an email address in the format [email protected]” removes the guesswork. Good errors are like a helpful shopkeeper: they point to the right shelf instead of merely saying that the item is elsewhere. Respect Zoom, Text Size, and Reduced Motion A responsive page should survive at 200% browser zoom without losing content or forcing horizontal scrolling for ordinary text. Prefer flexible layouts, relative units, and containers that can grow. Avoid locking text inside fixed-height boxes. Users should also be able to enlarge text without controls overlapping or disappearing. Animation can clarify change, but unnecessary movement may distract or cause physical discomfort. Honor prefers-reduced-motion and provide controls for carousels or media that starts automatically. This does not require deleting every transition. It means separating essential feedback from ornamental movement and offering a calmer route when the operating system requests one. Test in Layers Instead of Trusting One Score Automated tools such as Lighthouse, axe, or WAVE can quickly find missing labels, invalid attributes, and many contrast problems. They are valuable spell-checkers, not editors. A perfect automated score cannot tell whether alternative text is useful, heading labels make sense, focus order follows the task, or instructions are understandable. Add a short manual routine to every meaningful redesign: navigate the page using only a keyboard, zoom to 200%, inspect it at a narrow viewport, check forced or high-contrast colors, and listen with a screen reader such as NVDA, VoiceOver, or Orca. You do not need to become an expert user before listening reveals problems. If the page announces “button, button, link, image” without useful names, the structure needs work. Prioritize blockers first. Fix controls that cannot be reached, content that cannot be perceived, and tasks that cannot be completed. Then address confusing structure and friction. Record what you test so accessibility becomes part of maintenance rather than a heroic audit performed once every few years. A Personal Website Can Improve One Release at a Time Accessibility is not a badge earned after one scan. Content changes, templates evolve, and new components introduce new risks. Fortunately, the strongest improvements are often modest: semantic HTML, visible focus, sufficient contrast, useful labels, meaningful alternatives, and respectful motion. These choices also tend to make a site faster, easier to maintain, and more resilient. I now think of an accessible personal website as a home where the host has cleared the path before guests arrive. It may not anticipate every need, but it does not knowingly leave chairs across the doorway. Start with one page, test it without a mouse, and fix the first barrier you encounter. If this guide helps you notice something on your own site, share what you changed in the comments so others can learn from the same practical step.
