Technical Guide to Websites

ESU 10 websites are expected to meet the Web Content Accessibility Guidelines (WCAG) 2.1, Level AA. The full standard is published by the W3C here: https://www.w3.org/TR/WCAG21/. It’s long and technical; this Technical Guide to Websites is meant to translate those requirements into clear, practical steps for developers and content managers.

Level AA is widely considered the baseline for a site that is “reasonably accessible for most people.” The core question every time you update a page is simple: Can a student, parent, or staff member with a disability use this page as easily as anyone else?

This resource provides step-by-step guidance, best practices, and real-world examples to help ensure that all ESU 10 web content is inclusive, usable, and compliant. From understanding core accessibility principles to applying technical fixes in code and design, this guide is your reference for building digital experiences that work for everyone. In day-to-day work, most of your impact will come from how you handle text, images, links, documents, and media.

1. Quick WCAG 2.1 AA overview (in human terms)

WCAG is built on four ideas. Your content must be:

1. Perceivable – People can see, hear, or otherwise access the content.

2. Operable – People can navigate and use it with keyboard or assistive tech.

3. Understandable – Content is clear and predictable.

4. Robust – Works with different devices and assistive technologies.

2. Images: Use alt text correctly (and mark decorative images)

Screen readers can’t see images. They read the alt text instead.

2.1 Important images: describe the purpose

Use alt text for photos, charts, diagrams, icons that act like buttons, etc.

Alt text examples

Photo of man eating pie: Jon enjoys eating an entire pie in one sitting

Button-style image that links to something: Order another pie for Jon

HTML examples

<!-- Informational photo -->

<img src="/images/haussler.jpg" alt="Jon enjoys eating an entire pie in one sitting">

<!-- Image used as a button/link -->

<a href="/lunch-applications"><img src="/images/lunch-icon.png" alt="Apply for free and reduced lunch"></a>

2.2 Decorative images: mark them as decorative

If the image adds no information (borders, background swirls, purely decorative clip art), it should be ignored by assistive tech.

There are two common ways to handle this:

1. In a CMS/image dialog

   • Many editors have a checkbox like “Mark as decorative” or “This image is decorative”. Use that whenever the image doesn’t convey meaning.

2. In HTML code

   • Optionally add role="presentation" or aria-hidden="true" for extra clarity.

HTML examples

<!-- Decorative line or border -->

<img src="/images/blue-divider.png" alt="" role="presentation">

<!-- Background flourish that adds no meaning -->

<img src="/images/abstract-swoosh.svg" alt="" aria-hidden="true">

Empty alt="" is the key. That tells screen readers: “Nothing useful here, skip it.”

3. Headings: Use real heading tags, not just big bold text

Headings are how screen reader users and keyboard-only users jump around a page. They also affect how tools like Lighthouse and WAVE grade your page.

3.1 Basic rules

• Use real heading tags: <h1> through <h6>, not just bigger or bold text.

• Only one <h1> per page (the main title).

• Use a logical order:

  • <h1> – Page title

  • <h2> – Major sections

  • <h3> – Subsections under a section, and so on.

• Don’t skip levels for no reason (e.g., <h2> straight to <h4>).

If you style something to look like a heading but don’t use an actual <h*> tag, screen readers and automated tools will treat it as regular text.

3.2 HTML example (good structure)

<h1>Middle School Counseling Services</h1>

<h2>How to Contact the Counselor</h2>

<p>Email or call the office to schedule an appointment.</p>

<h2>Services Offered</h2>

<h3>Individual Counseling</h3>

<p>Students can request one-on-one meetings with the counselor.</p>

<h3>Group Counseling</h3>

<p>Small group sessions are offered throughout the year.</p>

3.3 When you’re using a template and CSS classes

Many templates define heading styles in CSS (e.g., .h1, .h2) that control how big or bold something looks. That’s fine, as long as the HTML tag matches the actual level of the heading.

Example

Your design wants the page title to visually look like your “H2 style,” but logically it’s still the top-level heading for the page.

Bad (no real heading, just styled text):

<p class="h1">Middle School Counseling Services</p>

Better (correct semantic heading, styled to look like an H2):

<h1 class="h2">Middle School Counseling Services</h1>

• Screen readers and tools like Lighthouse/WAVE see this as an <h1> (correct for a page title).

• The CSS class h2 only controls how it looks (size, font, etc.).

You can use this pattern anywhere you need the semantic level of the heading to be correct but want to reuse a different visual style from your template.

4. Links: Make link text actually mean something

“Click here” is useless out of context.

4.1 Good link practices

• Describe where the link goes or what it does:

  • Good: Download the 2025–26 school calendar (PDF)

  • Bad: Click here or More

• If it opens/downloads a file, say the file type:

  • Field trip permission form (PDF)

4.2 HTML examples

<!-- Link to a PDF -->

<a href="/docs/calendar-2025-26.pdf">Download the 2025–26 school calendar (PDF)</a>

<!-- Link to an online form -->

<a href="https://example.org/enrollment">Online enrollment form</a>

5. Color & contrast: Your text has to be readable

WCAG 2.1 AA requires a minimum contrast between text and its background so that users with low vision or colorblindness can read it.

5.1 Quick rules

Use dark text on a light background (or light text on a dark background).

Avoid light gray text on white or pale backgrounds.

Don’t put important text directly on top of busy photos or patterns.

Don’t use color alone to convey meaning (e.g., “items in red are required”).

Example (acceptable contrast):

<p style="background-color: #ffffff; color: #222222;">

  The school office is open from 7:45 a.m. to 4:15 p.m.

</p>

The inline styles here are just for illustration; in real sites, this is usually handled in CSS.

5.2 Checking contrast with tools

You don’t have to guess. Use tools to check whether your color combinations meet WCAG 2.1 AA contrast requirements.

WebAIM Contrast Checker

https://webaim.org/resources/contrastchecker/

Enter the foreground color (text) and background color (page or container).

It shows whether the combination passes WCAG 2.1 at Level AA or AAA for normal and large text.

Just Color Picker (Windows)

https://www.majorgeeks.com/files/details/just_color_picker.html

Lets you pick any color from your screen (for example, from a mockup or existing page).

Copy the hex value (like #004c97) into the WebAIM Contrast Checker to test it.

Workflow in practice:

Use Just Color Picker to grab the text color and background color from your design.

Paste both hex values into the WebAIM Contrast Checker.

If it fails Level AA, adjust the colors until the checker says “Pass.”

This gives you a concrete way to back up “this looks readable” with “this is WCAG-compliant.”

6. Keyboard navigation: Test without a mouse

Some users navigate entirely by keyboard.

Quick test:

Open the page.

Press Tab repeatedly.

Confirm:

You can see where focus is (button/link gets an outline).

You can reach menus, links, and form fields.

You can activate important items with Enter or Space.