What Is the Interface Actually Made Of?
When two interfaces look the same, what makes them different to the browser and assistive technology?
This session introduces the idea that a webpage has both a visual presentation and an underlying semantic structure communicated by HTML and browser accessibility information. Students inspect structure, controls, and forms briefly, then begin the individual MakerMap review with a concrete first pass before they return to the same experience with a screen reader in the next class.
Look at the page, then look underneath
A page can look polished while still hiding meaning from the browser. CSS can make a block look like a heading, a button can be styled to look like a link, and a form control can appear clear while still lacking the semantics that assistive technology needs.
Use the Structure demo to compare what appears to be a heading with what the markup actually says. Ask: What appears to be a heading? What does the markup say is a heading? What order does the document actually contain?
CSS controls appearance. HTML communicates structure.
Keep the comparison concrete:
- visually obvious headings versus actual HTML headings
- page regions and landmarks versus visual grouping
- source order versus the apparent visual order
Controls matter too
The same principle applies to interaction. A link, a button, a checkbox, and a text field are not just decorative shapes. They carry information about purpose, behavior, and state that the browser and assistive technology can expose.
Browse the Controls demo selectively: compare a link and button, a native button and clickable div, a checkbox, a radio group, an email input, a disclosure, and an icon-only button. The goal is practical: students should see that HTML communicates purpose, behavior, grouping, name, and state.
CSS can make controls look alike. HTML determines what the control actually is.
Choose a few examples for live discussion; the rest are available to explore:
- Is this a link or a button?
- What does the native control already know how to do?
- Do these choices belong to one question?
- What name or state does the browser understand?
Forms require labels, instructions, and recovery
Forms are the clearest place to see how structure, meaning, and error recovery work together. Students need labels, helpful instructions, correct grouping, clear required information, and an error message that helps the user recover without losing valid work.
Use the Workshop Registration form demo to demonstrate the core idea: a form should communicate what is required, how to answer, and what the interface expects before the user is forced to guess. Do one intentional mistake and watch the recovery path.
The goal is not a full error-handling lecture. It is a short, concrete look at how good form communication reduces user cost and protects work already done.
Make the discussion explicit:
- labels and instructions must be present and persistent
- grouping helps communicate relationships
- required information should be clear
- errors should identify the problem and preserve valid work
Challenge 05: Accessibility Review
Challenge 05 is a 10-point individual review. MakerMap contains 20 deliberate issues across Modules 01–05; students identify all 20 in the completed assignment, not during either class session.
Begin by understanding the task and testing MakerMap in multiple ways. Automated output is not proof of accessibility, and AI output is not evidence.
Start Your Review
Open MakerMap and keep the first pass methodical. Session 10 begins the review; it is not a requirement to complete the assignment in class.
Starting in Session 10?
Challenge 05: Accessibility Review
Begin the multi-method review and record candidate observations. Screen-reader testing follows Session 11; completing all 20 is not expected during class.
Open the challengeFollow this first-pass procedure:
- Complete the task normally. Use MakerMap to find a creative space for a project, compare resources, review location and orientation information, and request an orientation.
- Start your Review Record. Record normal use, browser/device, and one meaningful observation. Use the Challenge 05 Review Record format.
- Make a visual/media pass. Review contrast, color dependence, text enlargement and reflow, the meaningful map, and the prerecorded orientation video.
- Put the pointer away. Try the important task again using the keyboard. Pay attention to what you can reach, what you can activate, where focus is, and whether any interaction assumes a pointer.
- Make a mistake in the orientation form. Observe its labels, instructions, group context, error communication, preserved work, and recovery.
- Record two or three candidate observations before class ends. They do not need to become final findings; note what happened and what you need to investigate further. Do not try to identify all 20 or finish the assignment during this session.
The purpose is to begin the investigation, not to finish it.
Not yet
Do not worry about screen-reader testing today. We will practice screen-reader navigation in Session 11, then return to MakerMap and add that testing to your review.
Do not begin by dumping an automated-tool report into your assignment. Students should understand the task before automated testing begins.
You are not expected to perform screen-reader testing yet.
Next: Test What You Cannot See
Next class you will choose a screen reader, learn enough of its navigation model to use it deliberately, practice on our demo pages, and then return to MakerMap for the screen-reader portion of your review.