Session 4: How can designers help dev in Accessibility? / HTML First Design
Author: Sebastian Greger
Starting point = workflow in an organisation:
- starts out with server-side generated
- just the content and navigation
- works well
- just imagine bare HTML: H1, paragraphs etc.
- layout added later
- everybody in the organisation loves it
- works really well for component-based design
q: if you do the html-first approach - is the first MVP deliverable just html code; how do you then liaise with visual designers? how do you turn this on the head: HTML turns into visuals?
- visual designers have been hired into ux roles, with coding knowledge etc.
- html skeleton can be merged with design components
- "take the css and drop it on the html"
- sell it as a time saver: if designers are not on board from the start, work has to be repeated
- developers can show ways that designers were not aware of
experience from an agency:
- communication between devs and designers; internal sessions helped designers to unlearn old restrictions, instead see new potential
- overlap with ux; a lot of a11y work is also invisible
= an education issue!
- a lot of the work to be done (esp. in large orgs) is about education: these things are doable, easy, don't interfere with product delivery
q: a11y work is easier when starting from scratch - how to approach this for an existing site, with a small team? a: gradually introducing changes
q: realizing that people use different tools for checking compliance (e.g. with color contrast tools). who defines what is the truth?
- standards! e.g. color contrasts are defined in WCAG
- you have to defined your conformance level q: is there the one tool for everything? (e.g. color contrast analysis tools disagreeing)
- "how much lacking contrast can we get awa with" -> that is not design, is dysfunction
- needs to come from someone who makes something of a creative decision
- agree on one tool within the company
opinion: "always assume you have boxes that can have any size or amount of content"
"therapy session": what do developers want designers to stop doing?
- try to provide readable labels with visual buttons
- don't do custom dropdowns (not possible to design accessibly) --> designers wanted to make it superbeautiful, but HTML has a limitation to style it cross-browser
- "i can do it poorly and badly accessible one quickly; the good version takes longer"; it is good for designers to know the limitations of existing native elements
- in agile: start with an accessible 1st version, then develop the visual style from there
- more involvement of designers
- article: "accessibility for designers"; comprehensive resource
- clarify what the designer really cares about and what they don't; devs tend to rally against a detail which turns out was actually not important to the designer --> expose designs early, talk about them, then discuss
- designers and devs have to work together closely: it's a communication problem (!!!)
- for example a divider line might not be important for a visually impaired user: break down what elements are important, and which aren't
- native select elements: on mobile much more accessible to have the native element
- design with real data
- get designer and developer next to one screen: dev can show the designer what can be done --> can be developed into pair programming
- question " what is a design file for?" --> initially, for sign-off. second use case: for the developer "this is what you should build" - what happens is that something designed for first use case is recycled in second
- generally there seems to be agreement on "education" (if you have users not invested in a11y, that is almost impossible to overcome)
- when starting with html, a11y is baked in from the start; question then becomes: how do we not screw it up in the process?
- always challenge the initial assumption: is a drop-down really the best solution - alice bartlett (now at financial times) wrote a good article on that; it's based on a conf talk, titled "the interface element of last resort" (is it https://www.youtube.com/watch?v=-dH6a6eMdXE ?); also check out luke wroblewsky, who has written a lot about that
- often developers have a design background: often can assist designers
- develop a shared language/nomenclature (design files, frontend etc.) can facilitate discussion and exchange
- information architecture: often overlooked aspect is the specification of what is a heading etc. - should be defined by a designer; often a missing part