Responsive day out 3: the final breakpoint

!/perch/resources/opening-.jpg! Jeremy Keith opening Responsive Day Out 3

Yesterday I attended the third (and hopefully not final) edition of Responsive Day Out, Clearleft’s one day conference about all things responsive web design.

The talks were very varied this year. There were practical talks about improvements to the web with features like Web Components, Service Workers and flexbox. There were also conceptual talks, which looked at meta issues surrounding responsive web design: how web designers and developers adopt new ways of working or choose not to do so, and how to work together.

Like "last year":/en/blog/2014-06-29-responsive-day-out-2-the-squishening, the conference was hosted by Jeremy Keith, talks were divided into four segments, with three short talks in each segment, followed by a short interview-like discussion.

h2. Part 1: Alice Bartlett, Rachel Shillcock and Alla Kholmatova

p(intro). In the first segment, Alice Bartlett looked at whether and how we might be able to come up with a business case for accessibility, Rachel Shillcock looked at the relationship between web design and accessibility and Alla Kholmatova did a fantastic talk about (libraries of) patterns and, amongst other things, how to name them.

h3. The business case for accessibility

bq. Coming up with a business case may be a much shorter route to getting everyone on board with accessibility

"Alice Bartlett": from the "Government Digital Service": opened with a convincing talk about how to sell accessibility. Designing and building websites accessibly is a no-brainer to web designers and web developers who are convinced by the moral case for accessibility. But to some, that argument won’t cut it. There may be people in your organisation that want to learn more about the return on investment, and instead of trying to make the moral case, coming up with a business case may be ‘a much shorter route’ to getting everyone on board with accessibility, Alice said.

A business case is a document that proves that you have a problem and shows how you can solve it in the most cost effective manner. For accessibility this is hard, as there is not much evidence to show that accessibility solves the problems that we assume it solves. Sites that are accessible may be more maintainable, better for SEO or beneficial to usability, but, said Alice, there is hardly any evidence supporting such claims. See also Karl Groves’ "series of blog posts": about this, and the "conclusion of that series":

Litigation may prove to be a way out: if non-accessibility is something one can be sued for, accessibility may be the result of a strategy avoiding being sued. The problem with that approach, is that whereas the risk of being sued is likely to be substantial for high profile companies, it is unlikely to be big enough to make a case for low profile companies. This should not stop us from making low profile companies’ sites accessible, but it does show that coming up with a business case for accessibility is problematic.

h3. Accessibility and web design

"Rachel Shillcock": is a web designer and talked about how she integrates accessibility in her web design workflow. She gave practical tips and discussed tools like Lea Verou’s "Contrast Ratio": for determining WCAG colour compliance, "HTML Code Sniffer": that checks your front-end code for potential problems in web accessibility guidelines compliance, and "tota11y":, a similar tool that was recently launched by Khan Academy. Rachel made the moral case for accessibility: she emphasised that accessibility is a responsibility and that improving it can hugely improve your users’ lives.

h3. Pattern libraries and shared language

"Alla Kholmatova": talked about the pattern library she works on at "Future Learn": One of the problems she highlighted, is the boundary between a component being just something on its own, and it having enough similarities to something else to form a shared component. Like in language, interpretations may vary. I may see two separate components, you may see one component and one variation. “Naming is hard”, Alla explained. Visual names like ‘pink button’ are easy, but will quickly become limiting and burdensome (to the project). Functional names may be better, but then you might end up with two components that have different functions, but are visually the same. Higher level functions could be the basis for better names.

Alla emphasised that language is incredibly important here, shared language in particular. Pattern libraries and frameworks for modular design like "atomic design": and "material design": are ‘examples of controlled vocabularies’, she said. Naming is the method teams use to establish such frameworks. The framework will be used by the team, therefore the naming should be done by the team that will use it. The language that is established should remain in use to stay ‘alive’ and keep its meaning. Because a name like ‘billboard’, one of Alla’s examples, is quite broad. By using it in daily conversations, it remains meaningful. It made me think of Wittgenstein, who "held": that language only has meaning in virtue of the group / community it is used in.

bq. Many of their naming conversations […] are done with everyone involved: not just designers or developers, but also content producers and users.

She explained how the team at Future Learn work on their shared language: they have a wall with all the (printed out) bits of design of their website for reference and overview. Many of their naming conversation takes place on Slack, and are done with everyone involved: not just designers or developers, but also content producers and users. They look at terminology of architecture and printing press for inspiration.

h2. Part 2: Peter Gasston, Jason Grigsby and Heydon Pickering

p(intro). In the second part, Peter Gasston talked about the state of web components, Jason Grigsby explained some of the puzzles of responsive images and Heydon Pickering showed how when viewing CSS as (DOM) pattern matches, clever CSS systems can be built.

h3. Web Components

"Peter Gasston": gave an overview of Web Components, which provides a way for web developers to create widgets or modular components, that can have their own styles and behaviour (as in: not inherited from the page, but really their own). React and BEM have provided ways to do that with existing tech, Web Components brings it to the browsers.

There are four key modules to Web Components: templates, HTML imports, custom elements and Shadow DOM.

  • Templates offer a way to declare reusable bits of markup in a @