agentleFS
Sign inStart free
opendatahub-ioopendatahub-io/docs-skills/skills/rh-ssg-accessibility/SKILL.md

rh-ssg-accessibility

Skill4 starsChanged 4 months agoApache-2.0View on GitHub

Review Red Hat documentation for accessibility compliance (WCAG) — alt text for images/icons, color not as sole information carrier, no directional language ("left"/"right"/"above"), descriptive link text (no "click here"), table structure (no irregular headers, no blank header cells), and correct heading nesting. Use this skill whenever checking Red Hat docs for accessibility, screen reader compatibility, alt text, link text, or WCAG compliance. This skill takes precedence over ibm-sg-audience-and-medium for accessibility checks on Red Hat content.

The file

Create a free account to mount
Files
SKILL.md

Red Hat SSG: Accessibility review skill

Review documentation for accessibility compliance with the Red Hat Supplementary Style Guide and WCAG guidelines.

Checklist

Colors and visual information

  • Color is not the only means of conveying information
  • Instructions do not rely solely on sensory characteristics (shape, size, visual location, orientation)
  • No directional indicators for navigation: "left," "right," "above," "below" have no meaning to screen readers
  • Information conveyed by color differences is also provided in text form
  • Images and diagrams have sufficient contrast between foreground and background

Images

  • All icons, images, diagrams, and non-text elements have meaningful alt text
  • Icon alt text describes function, not appearance: alt text for + icon is "Add" not "Plus Sign"
  • No images of text — use actual text to convey information
  • Screen captures of informational tables are replaced with actual tables

Links and hypertext

  • Link purpose is clear from the link text alone (or link text with context)
  • No generic link text: "click here," "here," "this page"
  • Links within a document show the section title
  • External links provide the site name or target page title
  • All links point to correct and valid destinations

Tables

  • Tables have a simple, logical reading order: left to right, top to bottom
  • No tables with irregular headers (multi-level headers, spanned rows/cells)
  • No blank header cells — add text to each header cell
  • All tables have descriptive titles/captions

Well-formed HTML and meaningful sequence

  • Headings are correctly nested: H1 > H2 > H3 (no skipped levels)
  • Content is presented in a meaningful order
  • Correct AsciiDoc tags produce the intended HTML output

How to use

  1. Review only changed content and necessary context
  2. For each issue found, cite the relevant SSG or WCAG section
  3. Mark issues as required (missing alt text, images of text, blank header cells, skipped heading levels) or [SUGGESTION] (improvements)

Example invocations

  • "Review this file for accessibility issues"
  • "Check images and tables for accessibility in assembly_overview.adoc"
  • "Do an SSG accessibility review on the changed modules"

References

For detailed guidance, consult:

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free