Inclusive design: some principles and notes

Written on 29 April 2018, 09:01pm

Tagged with: , , ,

Time to mix IT security with web design, so a few notes from the first chapters of Inclusive Design Patterns, by Heydon Pickering.

Some basic principles:
– always use semantic structures (ex. use the lang attribute)
– prefer existing HTML elements instead of inventing new structures. In other words, embrace standard behavior. If you can use a native HTML element, then do so.
– use progressive enhancement: HTML, then add CSS, then add JS (also known as ‘content first design’)
“If it’s not curlable, it’s not on the web”
Henny Swan UX principles: give users choice, put the users in control, design with familiarity in mind, prioritize features that add value
– remove redundancy (ex. instead of having a logo and a ‘home’ label both pointing to the homepage, consider turning the logo into a navigation link)

Fonts:
– never use absolute font size (ex. 16px), use the relative measures
– use rem over em to avoid font size nesting problems
– font display problems (especially when using web fonts): FOIT – Flash of Invisible text, FOUT – Flash of Unstyled text. See SmashingConf London — Zach Leatherman on ‘Web Fonts are ▢▢▢ Rocket Science’
– start using font-display: swap, optional, fallback (Chris Coyier – If you really dislike FOUT, `font-display: optional` might be your jam)
– when using web fonts, you can specify to download only the characters that you need: https://fonts.googleapis.com/css?family=Roboto&text=ABCDEFGH

Accesibility:
– try to navigate your website using only the keyboard: skip links, tab index, highlight the focused element
– the ‘skip to content’ links are mostly for sighted, keyboard-only users
– make sure that all the elements are focusable, that the focused element is visible and highlighted
– try to navigate your website using a screen reader
– design for the extremes:
– design for the people with poor networks: the ones with good networks will also be happy
– design for the people with readability problems (ex. dyslexia or color vision deficiency): the other users will also benefit
– always provide alternative text
– don’t differentiate by color alone
– don’t make the touch targets too small (believe it or not, everybody has fat fingers)

Do not break conventions:
– allow pinch to zoom
– use blue and underlined links (color is not sufficient, use underline as well)

The human brain uses patterns called schemata to understand sense data. Schemata constitute prior experience against which current experience is evaluated.
In programming terms, schemata are a kind of cache for understanding. So long as a familiar thing is being experienced, little more effort is required to understand it.
By the same token, if something genuinely new is experienced, there’s nothing in the cache to be relied on and thesense data must be evaluated in full
smashingmagazine.com/inclusive-design-patterns/

Design
– prefer left align of text instead of justified (especially for narrow columns)
– be careful with the line height: the users will zoom in. Never use absolute font size!
– warn the users about the external links
– automatically add icons from CSS instead of the WYSIWYG editor (example: icons for the external links that will open in a new tab)
– make the link texts descriptive
– if you use video, think about closed captions. They are not only for the users with hearing problems (ex. watching it without volume)
– don’t be afraid of using relative #links in the navigation menu
– SVG is probably the best option to design the hamburger MENU button (instead of image, font, unicode character, etc)
– if you have an online store, use microdata to have rich snippets in the search results
– if you have to implement infinite scrolling, then consider having a ‘load more’ link for the keyboard users. Or think if it’s the right thing to do 🙂
turn the placeholders into labels when the users start typing

Content
– follow the ‘content-first’ guidelines
– keep it short, avoid passive sentences, eliminate redundancy, vary the length of sentences
– use readability tests (ex. Flesch)
– when creating your headings, think about the table of contents (do the headings still make sense when reading in the ToC?)
– don’t make your site content dependent on client-side JavaScript
– everybody loves table of contents, especially if the content is long

In the end, a strong conclusion: it’s all about the end result. What we have to design is processes, not screens.

People are not really into using products. Any time spent by a user operating an interface, twisting knobs, pulling levers or tapping buttons is time wasted. Rather, people are more interested in the end result and in obtaining that result in the quickest, least intrusive and most efficient manner possible.
We will design processes, not screens.
We will design systems, not individual pieces.
We will design less “using,” and more getting results.
– Goran Peuc – Nobody Wants To Use Your Product

Comments (1)

Leave a response