Inclusion Code

Accessible HTML practice for blind learners, focused on web accessibility

Web accessibility matters

Understanding HTML empowers blind users to shape web accessibility.

For blind people, a website can be a doorway to education, work, services, and community life — or a locked barrier. Web accessibility works best when blind users are involved in the process.

Inclusion Code is an accessible HTML basic editor that introduces blind learners to HTML code and helps them practice while building a direct understanding of web accessibility. It is designed especially for blind learners, who do not need to be programming experts to begin. In fact, becoming confident with web accessibility is only possible by first understanding HTML at a basic level. By learning how HTML structures content and how that structure is interpreted by screen readers and Braille displays, users can better understand what they experience every day , and gradually move toward deeper, more meaningful participation in accessibility work, such as identifying issues, explaining them clearly, and supporting real, practical fixes. Inclusion Code is developed by a blind educator, with blind users at the center of its design.

Designed to be screen-reader & Braille-friendly

Automated checks vs. manual accessibility review

Automated tools help with

  • Finding common patterns quickly (e.g., missing labels, some contrast issues).
  • Providing early feedback to prevent frequent mistakes.
  • Improving consistency during development.

But manual review is essential for

  • Real usability with keyboard, screen reader, and Braille.
  • Meaningful alternative text (not just “alt exists”).
  • Logical heading structure, reading order, and focus order.
  • Clear forms, errors, instructions, and task completion.

Manual testing becomes more powerful when the evaluator understands HTML structure (headings, landmarks, labels, links, forms). That’s why learning basic HTML is a practical pathway for blind people to influence accessibility changes more directly.

How I do a 10-minute manual review (keyboard + screen reader)

This quick pass will not replace a full audit, but it often reveals the most impactful problems fast. (Works well with NVDA/JAWS/VoiceOver/TalkBack + keyboard navigation.)

  1. Keyboard only: Press Tab from the top. Can you reach everything? Any “keyboard traps”?
  2. Visible focus: Do you always know where you are (focus indicator clear)?
  3. Skip link: Is there a “Skip to main content” link that works?
  4. Headings: Use H navigation. Do headings describe sections logically (H1 then H2, etc.)?
  5. Landmarks/regions: Can you jump to navigation/main/footer easily?
  6. Links: List links. Do they make sense out of context (avoid “click here”)?
  7. Forms: Check each input. Is there a proper label? Are errors announced and understandable?
  8. Buttons & controls: Are names/roles/states announced correctly (“expanded/collapsed”, “checked”)?
  9. Images: Are images intentionally handled—described when they convey information or context, and intentionally ignored only when they are truly decorative?
  10. Language check: Listen with a screen reader. Is the page read in the correct language and clearly understandable?

For a blind person, learning HTML helps connect what they hear and feel through a screen reader or Braille display to what needs fixing in the code: headings, labels, landmarks, link text, and structure.