Starvard.
Starvard University · Web Accessibility 101
You will build and check websites and documents that people with disabilities can actually use. This course follows the W3C Web Accessibility Initiative tutorials and the WCAG 2.2 quick reference, turning the standard into plain steps you can practice on any page: structure, text alternatives, contrast, keyboard use, forms, media, and documents.
Hello, my name is Finn, and I'm going to help you understand this course.
Here it is, explained like you are 10:
Some people cannot see a screen, hear audio, or use a mouse, so they use the web in other ways, with tools that read pages aloud, with a keyboard, or with zoom. Accessibility means building pages so those ways work too. This course teaches you clear headings, text for images, strong color contrast, friendly forms, and captions, plus simple checks you can run yourself to find and fix barriers before real people hit them.
The W3C Web Accessibility Initiative, called WAI, explains that web accessibility means websites, tools, and technologies are designed so people with disabilities can use them: they can perceive, understand, navigate, and interact with the web, and contribute to it too. WAI develops the Web Content Accessibility Guidelines, called WCAG, which many laws and policies point to around the world.
This course turns that guidance into everyday habits. You will give every image a useful text alternative, keep headings in a clear order, make sure text is easy to read against its background, and check that everything works with a keyboard alone. You will also caption videos, make documents that screen readers can follow, and test your work with free tools and your own careful eyes.
The whole course in brief
What you will be able to do after this course
The eleven lessons
Lesson 1
W3C WAI puts people first: web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them. More specifically, people can perceive, understand, navigate, and interact with the web, and contribute to it. A page that blocks any one of those steps blocks the person, no matter how attractive the page looks.
WAI lists the disabilities that affect access to the web: auditory, cognitive, neurological, physical, speech, and visual. One person may use a screen reader that speaks the page aloud. Another may navigate by keyboard or by voice. Another may zoom the text large, or rely on captions. Accessible design respects all of these ways of working instead of designing for one imaginary average visitor.
Accessibility also helps people without disabilities. WAI points to people using phones and small screens, older people with changing abilities, people with a temporary problem such as a broken arm or lost glasses, people in bright sunlight or in a place where they cannot listen to audio, and people on a slow connection. Build for the edges and the middle gets easier too.
Think of a friend reading your site on a phone in bright sun, one handed, with a train announcement drowning the speaker. That ordinary moment is an accessibility moment. Designing for people with disabilities and designing for real life turn out to be much the same kindness, practiced on purpose.
Lesson 2
The Web Content Accessibility Guidelines, called WCAG, organize accessibility under four principles, often shortened to POUR. Information and the user interface must be perceivable, the interface and navigation must be operable, information and operation must be understandable, and content must be robust. WAI teaching materials use these four ideas as the foundation that every requirement hangs from.
Perceivable means people can take in the content with the senses they use: text alternatives for images, captions or transcripts for media, and sufficient contrast between text and background. Operable means people can work the controls: navigation using only a keyboard, meaningful links, and enough time to finish a task. If a person cannot perceive it or operate it, nothing else on the page matters yet.
Understandable means content reads clearly, pages behave predictably, and the design helps people avoid and correct mistakes. Robust means content works reliably with current and future tools, including browsers and assistive technologies. The WCAG 2.2 quick reference, called How to Meet WCAG, lets you filter the success criteria and techniques, so keep it open while you work through the rest of this course.
Levels help you aim. WCAG criteria carry levels, and many policies treat Level AA as the working target because it covers the barriers that lock people out most often. You do not need to memorize the whole standard. You need the principles in your head and the quick reference at your elbow.
Lesson 3
Headings are the map of your page. WAI writing guidance says to use short headings to group related paragraphs and clearly describe the sections, because good headings provide an outline of the content. A person scanning visually skims that outline in seconds. A person using a screen reader can call up the same outline as a list and jump straight to the section they need.
Use real heading markup, in order, and let the level carry the structure. One main heading names the page, the next level names its major sections, and a deeper level names parts inside a section. Do not choose a heading level because you like its size, and do not skip levels to make text look bold. Visual styling can change; the structure underneath should stay honest and predictable.
The same habit applies to the rest of the page. Use list markup for lists, give each page an informative and unique title, and write link text that describes where the link goes, instead of vague words that only make sense when you can see the surrounding design. WAI suggests putting the unique and most relevant information first in a page title. Structure is invisible when it works, and painful when it is missing.
WAI writing guidance adds small habits with large effects: expand acronyms on first use, keep sentences and paragraphs short and clear, and use list formatting where it helps. Plain language is an accessibility feature. A confused reader and a blocked reader are in the same position: outside your content, looking in.
Lesson 4
Every image needs a text alternative that serves the same purpose as the image. The WAI images tutorial explains that the right alternative depends on why the image is there. For an informative image, write at least a short description that conveys the essential information. For a chart or diagram, provide a full text equivalent of the data and information it shows.
Some images work rather than inform. The alternative for an image used as a link or button should describe the function, not the picture: a printer icon should say what it does, not what it looks like. Images of text should generally be avoided, and when they are used, the alternative should contain the same words. If several images together convey one piece of information, one alternative can carry the whole group.
Decorative images are the honest exception. If an image only adds visual interest and conveys no information that matters for understanding the page, give it a null text alternative, written as alt with empty quotes, so assistive technology can ignore it. The quick test for any image is simple: close your eyes, listen to the alternative, and ask whether you lost anything that matters.
Keep a short decision habit for images in a series. Ask what the image does on this page, in this place, next to this text. The same photograph can be informative in one article, decorative in another, and functional in a third. Context, not the file, decides the alternative.
Lesson 5
Color should never be the only messenger. The WCAG 2.2 quick reference states the rule plainly in its Use of Color criterion: color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. If a chart, a form error, or a required field speaks only in color, people who perceive color differently get silence instead of information.
Contrast gives that rule numbers you can check. Success Criterion 1.4.3, Contrast (Minimum), at Level AA in the WCAG 2.2 quick reference, says the visual presentation of text and images of text has a contrast ratio of at least 4.5:1, and large scale text has a contrast ratio of at least 3:1. Logotypes and purely incidental text are among the stated exceptions. Check your main text, your links, and your button labels first, because those carry the page.
Build the habit of pairing every color signal with a second signal. Add a label, an icon, a pattern, or a position change alongside the color. Test your palette with a contrast checker before you fall in love with it, and be suspicious of pale gray text on white, however elegant it looks on your screen in a bright room. Readability is a feature, not a decoration.
Remember that contrast is about the pair, not the single color. A brand color that fails against white may pass against a dark background, and a button can often be fixed by deepening one shade instead of redesigning the whole page. Small, measured changes usually get you to a passing pair.
Lesson 7
Forms are where people give you their time, their money, and their trust, so forms deserve special care. The WAI forms tutorial starts with a simple preference: users prefer simple and short forms, so only ask for what is required to complete the task. Every extra field is a cost you charge the visitor, and people abandon forms that ask for too much.
Label everything, and group what belongs together. The tutorial teaches labeling controls with the label element, grouping related controls so their connection is clear, and providing instructions that help people understand how to complete the form and each control. Good labels help everyone: people using screen readers hear the label with the field, people using speech input can activate a control by its label, and people with limited dexterity get a larger clickable area when the label works too.
Errors will happen, so handle them kindly. The tutorial covers validating input and notifying users about successful completion and about errors, with instructions to help them correct mistakes. Say what went wrong in plain words, point to the exact field, keep the information the person already entered, and never blame them. WAI writing guidance adds that instructions, guidance, and error messages should be clear, easy to understand, and free of unnecessarily technical language.
Before you publish a form, fill it in wrong on purpose. Leave a required field empty, mistype a date, and submit. Read the error messages as a stranger would, with no knowledge of your system. If a message would not help your neighbor fix the form, rewrite it until it would.
Lesson 8
Just as images are not available to people who cannot see, audio is not available to people who cannot hear. WAI uses that parallel to explain transcripts: providing a text transcript makes audio information accessible to people who are deaf or hard of hearing, and also to search engines and other technologies that cannot hear. The same thinking covers video, with one addition: moving pictures carry sound that many people cannot access.
For audio and visual content such as training videos, WAI writing guidance says to also provide captions. Include in transcripts and captions the spoken information and the sounds that matter for understanding, such as a door creaking. For video transcripts, also describe the important visual content, such as a person leaving the room. Captions help far beyond their first audience: people watching in a loud place, or in a library where sound would disturb others, rely on them too.
Plan media accessibility before you record, not after. Write a script you can turn into an accurate transcript, check auto generated captions line by line and fix names and technical words, and keep the transcript on the page or one clear click away. A video without captions quietly tells part of your audience that the content was not made for them. A captioned one says the opposite, out loud.
WAI makes a helpful distinction in its media guidance: captions present speech and important sounds in time with the video, while a transcript presents the content as a readable document. Many videos deserve both. The transcript also makes your content searchable, quotable, and easy to skim.
Lesson 9
Documents fail in familiar ways. A scanned page is a picture of text, so a screen reader finds nothing to read. A report exported carelessly loses its heading structure, its reading order scrambles, and its images arrive with no alternatives. The fix starts earlier than the export button: build the document accessibly, in the same spirit as an accessible web page.
Use real heading styles in order, real lists, and meaningful link text in the source document, and write alternatives for images that carry information. Keep the reading order logical, because assistive technology follows the document structure, not the visual layout. When you export to PDF, preserve that structure as tags rather than flattening the document into ink. A well structured source document usually produces a far better PDF with far less repair work afterward.
Then check the result like a reader would. Open the PDF, try selecting and copying a paragraph, listen to a page with a screen reader if you can, and tab through any form fields in order. If the copy comes out scrambled, the order is wrong for everyone using assistive tools. Where a document matters a great deal, consider offering the same content as an accessible web page as well, which is often the friendliest format of all.
Tables inside documents need the same care as tables on the web. Give a table a clear header row, keep its structure simple, and avoid using layout tables or merged cells that scramble the reading order. A screen reader reads a table cell by cell, and it needs the headers to make sense of each one.
Lesson 10
WAI is honest about tools: evaluation tools help with evaluation, but no tool alone can determine whether a site meets the accessibility guidelines, and knowledgeable human evaluation is required. That is good news for a beginner. Your own careful checking, done in a sensible order, is real testing, not a poor substitute for an expensive audit.
Start with the checks you already own. Tab through the page with a keyboard. Zoom the text to 200 percent, the resize level named in the WCAG 2.2 quick reference, and confirm nothing is lost or broken. Read the page outline through its headings. Then run a free automated checker on the page and treat its report as a to do list: it will catch missing alternatives, contrast failures, and unlabeled fields quickly, even though it cannot judge whether your alt text is actually good.
Finish by listening. Free screen readers are available for every major platform, and even a short session, navigating by headings, links, and landmarks with your screen dark or your eyes averted, teaches more than an hour of reading about accessibility. Evaluate early and throughout a project, as WAI advises, so problems surface while they are still cheap and easy to fix. Write down what you tested, so the next person can repeat it.
Keep a one page testing note for each project: the date, the pages checked, the tools used, and what you fixed. That humble record turns accessibility from a memory into a practice, and it is exactly the evidence that your future self, your team, and your visitors will thank you for.
Lesson 11
This lesson is general information about the legal landscape, not legal advice for any specific site or organization. The broad pattern is consistent: WAI notes that web accessibility is required by law in many situations, and many laws and policies around the world point to WCAG as the technical standard they expect sites to meet. Knowing the names and the shape of these rules helps you talk sensibly with employers and clients.
In the United States, the Americans with Disabilities Act, usually shortened to ADA, is the civil rights law most often discussed for websites and services open to the public, and Section 508 is the part of federal law that requires federal agencies and their suppliers to make their electronic and information technology accessible. In Europe, the European Accessibility Act extends accessibility requirements across a range of products and services in the European Union. Details, deadlines, and duties differ by place and sector, and they change over time.
The practical response does not require a law degree. Pick WCAG Level AA as your working target, document the checks you run, fix barriers promptly when someone reports them, and write accessibility into contracts and purchasing so new tools arrive accessible. If your organization faces a specific legal question, ask a qualified professional in your jurisdiction. Good practice, done steadily and recorded honestly, is both the ethical answer and the safest habit.
Policies inside an organization matter as much as laws outside it. A short written commitment, naming WCAG as the standard and giving someone ownership of accessibility, prevents the slow drift back to inaccessible habits. Rules on paper only help when a real person is charged with keeping them alive.
Sources
This course is built from the W3C Web Accessibility Initiative (WAI) resources and the WCAG 2.2 quick reference, called How to Meet WCAG. WAI supplies the people first framing, the four principles, and the tutorials on images and forms, and the quick reference supplies the testable criteria, including contrast and keyboard requirements. All teaching prose here is original.
Graduation
You learned who accessibility serves, the four WCAG principles, and how to handle headings, alt text, color and contrast, keyboard navigation, forms, captions, and accessible documents. You practiced testing with keyboards, zoom, free tools, and screen readers, and you saw the main laws and policies in general terms. Every page you build from here can welcome more people, on purpose.
Keep learning
This course is part of Starvard University, striving for greatness.
A note on accuracy: Much of what you read at Starvard was created with help from AI agents, working alongside people. We check what we can, but we cannot guarantee that everything here is true, current, or complete. If something really matters, your health, your money, a grade, a job, please verify it with a trusted source before you rely on it.