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 attribute completely.
  • Nameless Graphic Links: Images placed inside link tags (<a>) where the link contains no text and the image's alt is empty. Assistsive devices read this as an empty, nameless link.
  • 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 (e.g., alt="hero-bg.jpg"), which is a common developer oversight.
  • Accessible Graphic Names: Standalone <svg> or <canvas> drawings 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.

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. Placeholders disappear once text is typed and are not read reliably by screen readers.
  • Empty Action Buttons: Interactive buttons (<button>) containing only icons, with no inner text, 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, which dictates what language screen readers use for voice synthesis.
  • Invalid BCP 47 Tags: Languages declared with incorrect tags (e.g. lang="english" instead of BCP-approved lang="en").
  • 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>), disrupting the visual and acoustic structure.
  • Empty Headings: Headers with no text content, which are frustratingly announced as empty elements by assistive devices.
  • 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="...", which breaks form label linkages, tab indexes, and ARIA relationships.
  • Focusable ARIA-Hidden elements: Interactive elements (such as links and buttons) with aria-hidden="true" applied. This renders them invisible to screen readers while remaining fully focusable by keyboard tab sequence, confusing blind users.
  • Disrupted Tab Orders: Interactive tags containing hardcoded positive tab indexes (e.g. tabindex="1"), which forces unnatural tab jumps.
  • Incorrect ARIA Roles & Attributes: Custom components using unrecognized role declarations or carrying invalid ARIA tag typos (e.g., aria-lable instead of aria-label).
  • 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 (like <div> or <span>) that trigger scripts via onclick listeners, but have no interactive role or tab index, rendering them invisible to keyboard-only users.

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 required to resolve ambiguity in complex tabular designs.
  • Orphaned Header IDs: Table cells referencing custom header IDs that do not exist in the DOM.