Text size, font, style, capitalization, size of all elements ➔ Leading, letter spacing, word spacing, justification, margins and borders, spacing between elements ➔ Heading hierarchy Field of vision ➔ Design layout Central field loss Peripheral field loss Other field loss
poor clarity of layout viewed with normal vision, and the same ticket machine viewed with poor peripheral vision. This shows a redesigned layout for the same machine, which enables the overall layout to be perceived, even with a peripheral vision loss. *Example from University of Cambridge’s Inclusive Design Toolkit
should make sense. ◇ ◇ Because screen readers navigate the page in DOM order, if you’ve used CSS to visually reposition elements, they may be announced in a nonsensical sequence. If you need something to appear earlier in the page, try to physically move it earlier in the DOM.
doesn’t need to be an aria-label (aria aids in description to screen reader users, doesn’t have to reiterate or override what might already be there, check that your aria is useful) ◇ It’s important to understand that ARIA can only affect the semantics of an element; it has no effect on the behavior of the element. ￭ For example, while you can make an element hidden to screen readers with aria-hidden=”true”, that does not change the focus behavior for that element. ◇ Remember, your aria-labels are for humans! (Don’t use aria-label=”form-control-1”) How do you know if you need a label? Is it understandable and clear without one? Make sure the html is semantic ﬁrst! First rule of aria! Only use labels when necessary to make it accessible
go from there? ◇ Accessibility guide and other a11y resources ◇ Is there an established practice? (WCAG is the standard) ◇ Nothing ﬁrm? Article documenting someone has done it before ◇ Try and test ◇ If not a ﬁrm standard/practice, test across use cases and platforms: ￭ Keyboard ￭ One or more screen readers (VO, NVDA, JAWS, etc.) ◇ Stuck? Ask for help! - ￭ web-a11y slack channel and other communities Resources