When I come across charts like this, this or this, my reaction is to point to obvious: that the information is unreadable by 1 in 12 men and in 1 in 200 women. Being one of them certainly helps to see the problem 🙂
Pointing it out is certainly good for raising awareness, but it’s not enough. Driving change is what ultimately matters. And the good news is, in most cases the change is really easy. So easy that I can resume it to two action points:

1. Don’t use color alone to convey meaning. Use icons, written content, and other visual elements to reinforce clear communication of the content.

https://accessibility.digital.gov/visual-design/color-and-contrast/

2. Make sure there’s sufficient contrast between graph colors so people with color blindness can distinguish the colors.

https://accessibility.digital.gov/visual-design/data-visualizations/

That’s it! Seriously. Add some symbols to your chart bars and pick a colorblind-friendly palette. Implementing the two points above will make your data visualization efforts more inclusive. If you want to go the extra mile and show some empathy, then

Test what it’s like to view your designs through a color blindness simulator

https://accessibility.digital.gov/visual-design/color-and-contrast/

The take away here is that “Designing for accessibility is not that hard“. As in the case of football, “This is not rocket science. It’s really about easy fixes“:

1. Accessibility is not only about screen readers and keyboard users. It’s about a system being accessible by anyone, from everywhere:
– if it’s too slow, it won’t load on poor connections
– if it only works in certain configurations (i.e. browsers), it won’t be accessible to everybody
– if the content it’s poorly written, too complex or difficult to be read then it’s not accessible

2. The impairment can be temporary (broken arm, eye surgery, etc) or situational (driving, party, theater). In my experience, I also found users that didn’t even know they had an impairment: they had a form of color vision deficiency (just like I do 🙂 ).

3. There is no drawback if you design with accessibility in mind (designing for the extremes). The non-disabled users will also benefit from this approach.

4. Add accessibility as a requirement early in the design. Think inclusive!

5. Challenge your team to use the system:
– using a screen reader
– without their hands
– on a browser without JavaScript
– from a poor connection (ex. Chrome Dev Tools can simulate this)

Resources:
Manuel Matuzović: My Accessibility Journey: What I’ve Learned So Far
W3C: Diversity of Web Users – How People with Disabilities Use the Web
Inclusive: A Microsoft design toolkit

Image source: https://medium.com/valtech-design/inclusive-design-dd4e03f82094

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

Weekend read. From @smashingmag pic.twitter.com/qkbo72HSu9

— Dorin Moise (@dorinmoise) March 30, 2018

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