Session 4: How can designers help dev in Accessibility? / HTML First Design

- | #dsndevcollab | #htmlfirst | Accessibility Club Meetup #8

Session notes

  • 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 ?); 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