Wpgeta site for everyone: an accessibility reference

An independent reference about website accessibility. We do not build websites to order or sell hosting, and we are not connected with the former site on this domain.

Guides

Practical guides

Most accessibility work doesn't require a developer. You need to know what actually gets in people's way and how to check for it on your own page. Here you'll find guides for problems almost every small website runs into, from pale text to a form you can't fill out without a mouse.

Every field label and every image description is a small fix that can open up the whole site for someone.

— Editor's note

About this section: the guides are written in general terms and aren't tied to any particular site builder or content management system. Setting names vary from tool to tool, so check your own tool's documentation; the purpose of each step stays the same.

Guides

Good places to start if your site is already live and you'd rather not rebuild it from scratch.

Make text readable

Raise the contrast of your body text, avoid tiny fonts and make sure the page doesn't break when zoomed in.

Tools

Describe your images

Give every meaningful image a short description, and leave the alt text empty on decorative ones so screen readers skip them.

Photo descriptions (in Russian)

Organize your headings

One main heading per page, sections one level below, subsections below that. Choose headings for meaning, not for big letters.

Glossary

Bring back visible focus

If you can't tell where you are when tabbing through the page, restore the focus outline or make it easier to see.

Fixes

Add captions to videos

Start with the videos that cover the most important topics. Captions help not only people who can't hear but also anyone watching with the sound off.

Comparisons

Article catalogue for English-speaking readers

Over time, this section will feature standalone Wpget articles written specifically for the English version of this reference.

What we plan to cover

  • How to write link text that makes sense out of context, without “click here”
  • Why color alone shouldn't carry meaning in charts, maps and status labels
  • How to write clear instructions and error messages for online forms
  • A quick accessibility checklist to run before publishing any new page

Editorial guidelines

  • Articles in this catalogue are written separately for each language version and are not translations.
  • Some articles link to third-party websites, including gaming services; we do not control their content, prices or terms.
  • We do not build websites to order and we do not publish advertising for studios, hosting providers or services, rankings, prices or reviews.

How to build a clear contact form

  1. Keep only the fields you need

    Ask yourself what you truly can't reply without. Every extra field is one more chance to make a mistake and one more reason to give up.

  2. Label every field

    Each field needs a visible label that's linked to it in the markup. Gray placeholder text inside the field doesn't count as a label: it disappears as soon as you type, and people forget what was asked.

  3. Mark required fields in words

    Write “required” next to the label or explain the symbol you use before the form starts. Color or an icon alone, with no explanation, isn't clear to everyone.

    Illustrative example: “Email (required)” is clearer than a red asterisk whose meaning is never explained.

  4. Explain the format up front

    If a field expects data in a certain format, say so in the label or just below it, before anyone types. Better still, accept different ways of writing it so people don't have to guess.

  5. Make errors easy to understand

    An error message should say what's wrong and how to fix it, and it should appear next to the field. A red outline with no text explains nothing to people who can't tell colors apart or can't see the screen.

  6. Test the form with a keyboard

    Tab through every field, fill them in and submit the form without touching the mouse. The tab order should match the order on screen, and focus should stay visible the whole time.

  7. Confirm the submission

    After submitting, show a clear message that the message was received and what happens next. Don't make it vanish after a couple of seconds: people may need time to read it.

  • Tools

    How to check a site yourself: browser zoom, the keyboard, high contrast mode, the built-in screen reader, color contrast checks and a markup validator.

  • Comparisons

    Conformance levels A, AA and AAA; alt text vs. captions vs. transcripts; subtitles vs. transcripts vs. sign language, laid out in comparison tables.

  • Fixes

    What to do when focus is invisible, text breaks on zoom, a button has no label, form errors make no sense or a video has no captions.

  • Risks

    Accessibility traps: impossible CAPTCHAs, vanishing messages, flashing content, short timeouts, scans instead of text and overlays that promise to fix everything.

  • Glossary

    Key terms explained: accessibility, WCAG, GOST R 52872-2019, contrast, alt text, focus, screen readers, captions and plain language.

Sources

  • W3C: WCAG 2.2 Recommendation
  • GOST R 52872-2019 (Russian national standard)
  • Wpget editorial materials

This information is stated in general terms as of the preparation date. Guidelines, browsers and reader habits change over time, so when in doubt, check the primary sources: the text of the WCAG guidelines and, for Russia, the current GOST R 52872-2019 standard.