Login Page Accessibility Checker

What this checks, and how to read the report

Two halves. The generic half is axe-core, the same engine most accessibility tools use, filtered to WCAG 2.1 level A and AA so nothing in the report is a matter of taste. The login-specific half is the list below: fourteen things that go wrong on sign-in screens and that a whole-site scanner will not frame as an authentication problem.

• Every field has a label

  WCAG 1.3.1, 3.3.2, level A

  A field with no label is an unmarked box to a screen reader. Placeholder text does not count: it disappears the moment someone types, and it is not read as a name for the field.

• Username and password fields declare their purpose

  WCAG 1.3.5, level AA

  The autocomplete attribute is what lets password managers, browsers and assistive technology know which box is the username and which is the password. Without it people have to type credentials by hand, which is the exact barrier 1.3.5 exists to remove.

• Required fields say so in code, not only with an asterisk

  WCAG 3.3.2, level A

  A red asterisk is a visual convention. Unless the field itself is marked required, someone using a screen reader hears nothing and only finds out after the form is rejected.

• Error text is linked to the field it describes

  WCAG 1.3.1, 3.3.1, level A

  An error message sitting next to a field is only connected visually. aria-describedby is what makes the browser read the message out when focus lands on the field it belongs to.

• aria-invalid is used correctly, not emitted empty

  WCAG 4.1.2, level A

  An empty aria-invalid attribute is treated as false by some assistive technology and as invalid by others, so the field's state becomes a guess. Emit it only when the field really is in error, and remove it when it is not.

• Page-level messages announce themselves

  WCAG 4.1.3, level AA

  "Invalid username or password" is the most important sentence on a login page. Without a live region it is painted on screen and never spoken, so a screen reader user gets a page that appears to have done nothing.

• The page declares its language

  WCAG 3.1.1, level A

  Without a lang attribute a screen reader reads the page in whatever voice it happens to be set to, so a French login page gets read with English pronunciation. It is one attribute.

• The show password control reports its state

  WCAG 4.1.2, level A

  A show/hide password toggle changes state when it is pressed. If that state is only conveyed by swapping an icon, nobody who cannot see the icon knows whether the password is currently visible.

• Controls that act like buttons are buttons

  WCAG 4.1.2, 2.1.1, level A

  A div with a click handler is not focusable, is not announced as a button, and does not respond to Enter or Space. Using a real button element gets all three for free.

• Text on the form has enough contrast

  WCAG 1.4.3, level AA

  Field text, hint text and error text need a contrast ratio of at least 4.5:1 against their background (3:1 for large text). Grey-on-grey hint text is the single most common failure on a login screen.

• Field borders and focus rings have enough contrast

  WCAG 1.4.11, level AA

  The edge of an input is what tells someone where to type, and the focus ring is what tells them where they are. Both are user interface components: they need 3:1 against what is behind them.

• The form works at 320px without sideways scrolling

  WCAG 1.4.10, level AA

  At 320 CSS pixels (a phone, or a desktop zoomed to 400%) the page has to reflow into one column. If it scrolls sideways instead, every line of the form has to be read by panning back and forth.

• Every control shows a visible focus indicator

  WCAG 2.4.7, level AA

  Removing the outline is the fastest way to make a login page unusable by keyboard: focus still moves, but there is nothing on screen to say where it is. If you remove the default, put something back.

• The keyboard reaches the submit button in a sensible order

  WCAG 2.1.1, 2.4.3, level A

  Tab order should follow the order things appear. A positive tabindex re-orders the whole page, and a control taken out of the tab order cannot be reached at all, which on a login page means the form cannot be submitted.

How to read a result

• Fails means the check found something specific and named the element it found it on. Fix these first, worst level first.
• Needs a look means the automated check could not settle it. Usually the page is doing something unusual, and a person has to judge.
• Not applicable means there was nothing on the page for the check to look at. It is not a pass. A password toggle that does not exist cannot fail.

What we do with the page

We fetch the URL once, strip every script from it, and render what is left inside a locked-down frame in your own browser to measure colours, focus and layout. The page content is never written to disk or to a database: a saved report holds the findings, the CSS selectors they point at, and the URL you checked. That is all.

The checker only reaches public http and https addresses on ports 80 and 443. Private, internal and cloud metadata addresses are refused, before and after DNS resolution.