To help me stay focused on the true task at hand, I have a points system. In all cases, whether I’m applying visual design, writing JavaScript behavior or structuring content, I ask who benefits from the way I’m approaching it. •1 point: it benefits me •10 points: it benefits a user/reader like me and with my setup •100 points: it benefits me, people like me, and users/readers unlike me, with differing setups One hundred points is what we’re aiming for here. — 43: 748-754
(Refer to the responses of my screen reader survey21 to gain an impression of the diversity.) — 94: 1669-1672
Because so many accessibility errors relating to assistive technologies are markup errors, and because markup errors are so easy to identify, we’ve grown up in an accessibility remediation culture that is assistive technology obsessed and focused on discrete code errors. Inclusive design has a different take. It acknowledges the importance of markup in making semantic, robust interfaces, but it is the user’s ability to actually get things done that it makes the object. The quality of the markup is measured by what it can offer in terms of UX. — 250: 4364-4368
Give users choice. 2. Put users in control. 3. Design with familiarity in mind. 4. Prioritize features that add value. — 267: 4635-4638
“If you can use a native HTML element or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.” — 268: 4653-4655
The infinite scroll13 pattern harnesses the user’s scroll behavior to automatically load new content at the point — 284: 4951-4954