Technical Guide to Websites
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.
WCAG is built on four ideas. Your content must be:
Perceivable – People can see, hear, or otherwise access the content.
Operable – People can navigate and use it with keyboard or assistive tech.
Understandable – Content is clear and predictable.
Robust – Works with different devices and assistive technologies.
Screen readers can’t see images. They read the alt text instead.
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>
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:
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.
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.”
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.
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.
<h1>ESU 10 Contact Us Page</h1>
<h2>How to Contact the Main Office</h2>
<p>Call the office during normal office hours.</p>
<h2>How to Contact the NIS Department</h2>
<p>Call Ben or Russ on their personal cell phones. They don't mind.</p>
<h3>How to Contact the Repair Department</h3>
<p>No need. Mike knows when computers need repair. He will contact you.</p>
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">ESU 10 Contact Us Page</p>
Better (correct semantic heading, styled to look like an H2):
<h1 class="h2">ESU 10 Contact Us Page</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.
“Click here” is useless out of context. Don't do it.
Describe where the link goes or what it does:
If it opens/downloads a file, it's nice to say the file type:
<!-- Link to a PDF -->
<a href="/docs/calendar-2025-26.pdf">Download the 2025–26 ESU 10 Calendar (PDF)</a>
<!-- Link to an online form -->
<a href="https://example.org/enrollment">Online enrollment form</a>
WCAG 2.1 AA requires a minimum contrast between text and its background so that users with low vision or colorblindness can read it.
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.
You don’t have to guess. Use tools to check whether your color combinations meet WCAG 2.1 AA contrast requirements.
WebAIM Contrast Checker
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.”
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.