Web Accessibility Guide: WCAG Basics

01Who Is Accessibility For?

Accessibility is often associated only with blind or low-vision users. The scope is much wider: people with color blindness, people who cannot use a mouse because of a broken hand, older users, people watching video on mute in a noisy place, and anyone looking at a phone screen in the sun.

That is why accessible web design is not an extra job done for a small audience but a better experience for everyone. Clear headings, readable text and predictable navigation make things easier for users without disabilities too.

Accessibility also supports search engine visibility. Proper heading hierarchy, descriptive link text and image descriptions largely overlap with the elements that help search engines understand a page.

02What Is WCAG?

WCAG (Web Content Accessibility Guidelines) are the web content accessibility guidelines prepared under the W3C. The guidelines consist of testable success criteria and are divided into three conformance levels: A, AA and AAA. For most organizations and regulations, the target is level AA.

WCAG is built on four core principles. Every criterion belongs to one of these principles; understanding the principles is more useful than memorizing individual criteria. You can reach the official text on the W3C WAI page.

03Color Contrast and Readability

At level AA, normal text needs a contrast of at least 4.5:1 against its background. For large text, meaning roughly 24 pixels and up, or 18.5 pixels and up if bold, the ratio drops to 3:1. A 3:1 ratio is also expected for interface components such as form borders and icons.

Beyond contrast there is one more rule: do not convey information by color alone. Marking required fields only with a red asterisk, or telling links apart only by color, leaves out users with color blindness. Use underlines on links and descriptive text for errors.

Text size is part of readability too. When a user enlarges text in the browser up to 200 percent, content must not be lost and the page must not break.

04Keyboard Navigation

Users who cannot use a mouse, or who navigate with a screen reader, move through a site with Tab, Shift+Tab, Enter and the arrow keys. So menus, buttons, forms and pop-ups must be fully usable with the keyboard alone.

• Visible focus: The focused element must be shown with a clear outline; do not remove the focus outline entirely with CSS.
• Logical order: The Tab order should follow the visual order.
• Skip to content link: A hidden link at the top of the page that skips the menu and jumps to the main content.
• No traps: You must be able to leave a pop-up with Esc or the keyboard.
• Real buttons: Use button and a tags for clickable elements instead of div.

<a class="atla" href="#icerik">Skip to content</a>
<header>...</header>
<main id="icerik">...</main>

05Alt Text and Images

Screen readers cannot see images; they read the text in the alt attribute instead. Alt text should briefly describe the image's function on the page. For a product photo, the product's name and distinguishing feature are enough; if there is text inside the image, that text should be written in the alt text too.

For purely decorative images, an empty alt value is used so the screen reader skips it. If a link or button consists only of an icon, what the icon does must be stated in text.

<img src="zeytinyagi.webp" alt="Cold-pressed olive oil in a 500 ml glass bottle">
<img src="dalga-deseni.svg" alt="">
<button aria-label="Open menu">
  <svg aria-hidden="true">...</svg>
</button>

06Forms and Screen Reader Compatibility

Forms are where accessibility problems appear most often. Every field needs a visible, programmatically associated form label. Placeholder text written only inside the box is no substitute for a label, because it disappears once the user starts typing. If the quote form on a corporate website or the checkout step of a store cannot be completed with a keyboard and a screen reader, that user cannot become a customer.

For screen reader compatibility, error messages should be tied to the relevant field and say clearly what to do: “Phone number must be 10 digits” instead of “Invalid input”. The page language should be declared with the lang attribute on the html tag (tr for Turkish); otherwise the screen reader reads the text with the rules of the wrong language.

<html lang="tr">
...
<label for="tel">Telefon</label>
<input id="tel" type="tel" autocomplete="tel"
       aria-describedby="tel-hata" aria-invalid="true">
<p id="tel-hata">The phone number must be 10 digits.</p>

When Should You Use ARIA?

ARIA attributes are for situations HTML cannot cover. The first rule is: if a built-in HTML element does the job, use it. Misused ARIA can cause more problems than no ARIA at all.

07Mobile and Touch Accessibility

Accessibility on a phone brings extra topics. At level AA, WCAG 2.2 calls for touch targets of at least 24×24 CSS pixels; larger targets are preferred for comfortable use. Small links squeezed side by side cause mis-taps.

Screen orientation should not be locked; content must work in both portrait and landscape. Settings that block zooming should not be used. You can find other points to watch on mobile in our mobile-friendly website article and on our mobile-friendly design page.

08The Most Common Mistakes

In the sites we review in the field, accessibility problems usually cluster around the same few points. The good news is that most of them can be fixed with small code changes, and users notice the improvement immediately.

• Light gray text on a light gray background, in other words insufficient contrast.
• Product images with empty alt text or alt text filled with the file name.
• Link texts that give no context, such as “click here” or “read more”.
• Choosing heading levels by appearance; jumping straight from H1 to H4.
• Dropdown menus that do not open with the keyboard and pop-ups that cannot be closed.
• Slides that start on their own and cannot be paused, and videos with sound.
• Hiding the focus outline entirely for the sake of design.

09How Do You Test Your Site?

Automated tools catch some of the problems but not all. The best result comes from combining tools with short manual tests. This check is a natural part of a good UI/UX design process; we explained the difference between the two concepts in our UI vs UX difference article.

1. Put the mouse aside and use the page with only Tab and Enter.
2. Run an accessibility report with Lighthouse in Chrome DevTools.
3. Listen to a few pages with the free NVDA (Windows) or the built-in VoiceOver (macOS, iOS).
4. Enlarge the text 200 percent in the browser and see whether the page breaks.
5. Turn off images and check whether the page is still understandable.