Steterly
Technical Reference & Disclaimer

Accessibility Scan Rules

Steterly scans your website against key WCAG 2.1 Level AA criteria to identify high-impact accessibility barriers. Below is a detailed list of what we scan, why it matters, and why automated tools alone cannot guarantee full compliance.

The Honest Limitations of Automated Scans

While Steterly is a powerful tool to catch common issues and flag obvious technical oversights, automated accessibility checkers cannot certify a website as fully compliant or 100% accessible.

Here is why manual evaluation is irreplaceable:

  • Subjective Context (30-50% Coverage): An automated scanner can verify that an <img> element has an alt description. However, a machine cannot tell if the alt text actually describes the image accurately or if it is unhelpful spam (e.g. alt="image_123_final_v2.png").
  • Keyboard & Focus Logic: The scanner checks for crude patterns like hardcoded outline: none style overrides. But only a human tester can verify if tab order flows logically, if interactive modals trap focus correctly when open, or if custom JavaScript controls are fully operable using just the keyboard.
  • Screen Reader Performance: True accessibility depends on how assistive software (like NVDA, JAWS, or VoiceOver) translates your page layout. Steterly acts as a crucial first line of defense to catch critical, programmatic errors, but it should be paired with manual human testing.

1. Images & Media (WCAG 1.1.1 & 1.2.1)

Assistive tech relies on correct tags and text transcripts to communicate graphic elements. Steterly crawls the DOM to verify:

  • Missing Image Descriptions: Image tags (<img>) or input buttons (<input type="image">) missing the alt, aria-label, or title attribute.
  • Nameless Graphic Links: Images placed inside link tags (<a>) where the link contains no text and the image's alt is empty.
  • Generic / Vague alt attributes: Image descriptions that use meaningless, redundant keywords like "image", "photo", or "graphic", which offer zero context.
  • Filename matches: Alternate texts that copy the source filename exactly.
  • Accessible Graphic Names: Standalone <svg> or <canvas> elements that lack fallback texts, titles, or aria-label tags.
  • Missing Tracks & Captions: Standalone <video> and <audio> files that have no captions or subtitle <track> tags.
  • Embedded Object Descriptions: <object> media elements missing fallback texts, titles, or accessible name tags.
  • Image Map Alterations: Use of active <area> elements missing alt texts, or obsolete server-side image maps (ismap attributes).

2. Forms & Inputs (WCAG 1.3.1, 3.3.2 & 4.1.2)

Forms must be highly structured so keyboard users can navigate, fill, and submit them successfully. We test:

  • Unlabelled Input Fields: Text fields, select drop-downs, and textareas missing an associated <label>, aria-label, or aria-labelledby.
  • Orphaned Labels: A <label for="x"> where the ID x does not actually exist on the page.
  • Duplicate Labels: Multiple <label> tags pointing to a single input field, which creates reader confusion.
  • Placeholder Abuse: Input fields utilizing the placeholder="..." attribute as their only accessible label.
  • Empty Action Buttons: Interactive buttons (<button>) or input buttons (<input type="submit|button|reset">) missing inner text, values, aria-label, or title.
  • Group Organization: Multiple checkbox or radio groups that share the same name but are not organized within a logical <fieldset> and <legend> structure.
  • Missing Autocomplete on Passwords: Password and credential fields lacking autocomplete values (WCAG 1.3.5 AA).

3. Heading Hierarchy & Structure (WCAG 1.3.1, 2.4.1 & 2.4.2)

A page's document model must follow semantic standards so screen readers can build an accurate outline of the content. We verify:

  • Language Declarations: HTML page headers missing the lang="..." tag.
  • Invalid BCP 47 Tags: Languages declared with incorrect tags.
  • Missing Page Titles: Document layouts completely missing the header <title> tag.
  • Skipped Heading Levels: Broken outlines where heading levels are skipped (e.g. jump from <h1> directly to <h3>).
  • Empty Headings: Headers with no text content.
  • List Structures: List items (<li>) and definition items (<dt>/<dd>) properly nested inside lists, and containing elements enforcing children rules (e.g. only <li> inside <ul>/<ol>).
  • Landmark Structure: Layouts with duplicate main landmarks (e.g. multiple <main> wrappers) or missing a structural main landmark entirely.
  • Obsolete Presentational Tags: Presence of legacy styling markup such as <marquee> or <blink>.

4. ARIA & Keyboard Navigation (WCAG 2.1.1, 2.4.3 & 4.1.2)

Assisitive software uses the Accessibility Tree and WAI-ARIA values to convey custom widgets. Steterly evaluates:

  • Duplicate IDs: Multiple elements sharing the exact same HTML id="...".
  • Focusable ARIA-Hidden elements: Interactive elements (such as links and buttons) with aria-hidden="true" applied.
  • aria-hidden body: Document body elements having aria-hidden="true" which blocks full screen reader content.
  • Disrupted Tab Orders: Interactive tags containing hardcoded positive tab indexes.
  • Incorrect ARIA Roles & Attributes: Custom components using unrecognized role declarations or carrying invalid ARIA tag typos.
  • Role-Required Attributes: Roles that require specific accompanying attributes to function (such as a role="slider" lacking aria-valuenow).
  • Non-Semantic Click Handlers: Layout blocks that trigger scripts via onclick listeners, but have no interactive role or tab index.

5. Data Tables (WCAG 1.3.1)

Data tables must clearly link columns and rows to their headers:

  • Missing Headers & Captions: Data tables (<table>) lacking accompanying labels, ARIA tags, or structural <caption> descriptions.
  • Missing scopes: Heading elements (<th>) missing the explicit scope="col" or scope="row" tags.
  • Orphaned Header IDs: Table cells referencing custom header IDs that do not exist or point to invalid cells in the table headers.