Grids… for long I have thought they are the trivial bit in front-end development. Many sites do not have much variation in column widths, so to use a ‘grid system’ would be a clear violation of the KISS principle. Now I think complex grid systems can be of great use in component-based front-end builds.

Note that the following may soon be obsolete, when we start describing layout in CSS using CSS Grid Layout (not widely supported at the time of writing)

My view is this: for large websites and organisations, in addition to having a component system, it makes sense to have one agreed-upon, shared-between-projects grid system.

What is a grid system?

By ‘grid system’, in this article, I mean a set of CSS rules written for the purpose of declaring grids in mark-up. These can be hand written, or generated by preprocessors (in which case they can be generated with custom options to fit a project better). Some agencies I worked with have rolled their own. Others use an open source one, such as Bootstrap’s.

Spanning columns through classnames

In this kind of grid system, grids are declared using classnames on HTML elements. Usually classnames are given to each row of columns, and then to each column within that row. A grid has a number of ’virtual’ columns (e.g. 12 or 16). Specific elements span a number of these virtual columns, e.g. a main column could be the first 8 out of 12, then the sidebar could be remaining last 4. In mark-up, classnames of each actual column determine how many virtual columns are spanned.

Complex structures full of features

Grid systems are, more often than not, convoluted structures of code. Not only do they contain percentages for any combination of columns imaginable, they often also have options to ‘skip’ columns, so that an element can start spanning columns after the columns it has skipped. Many also contain percentages per breakpoint, so that you can have different sets of columns per breakpoint. This results in many classnames; time consuming to write, or if generated, buried away in your preprocessor output.

As opposed to the introducing-columns-when-required approach

Note that there are other ways to go about columns and widths in websites. You could just add CSS rules for each grid variation required (eg, you would be done by just writing one for doubles, one for quarters, and perhaps one for three quarters). This is how websites have been built for a long time. I used to prefer this approach — depending on the project, I sometimes still do. It uses a lot less CSS and is very KISS.

How do they fit in component-based front-ends?

The cool thing about component-based front-ends is that none of the component code is committed to specific widths. The width of a component is determined by the container it happens to exist in. Or, if it does not sit in a container, by the window or viewport width.

If your team decides to build pages using a grid system, this is their role: they force what the width is of any components that occur in the page.

To have a super complex grid system, with perhaps more classnames generated than you might actually need, requires clear advantages to be worthwile. The amount of classnames comes with weight: Bootstrap’s default grid system is 8KB (minified). Yet, advantages do exist:

Separation of generic, reusable components and specific, non-reusable widths

You don’t want the development of a new component to involve widths, the width of things will be decided in the context of the page grid and the viewport it exists on. Therefore, a separation between things and their widths makes sense. If the grid is separate, it makes sense to be a powerful (or complex) system that fits many cases, rather than something that is decided case by case.

Great for teams in agencies or organisations

As a team (in an agency or elsewhere), it makes sense to use the same grid system or grid system generator for all projects, with only changes to their setup (eg number of columns, nature of breakpoints). This is not about developer convenience, it is about organisational consistency. You’re making sure all teams in your organisation do the same thing with their widths, just as they do the same thing with their components.

Conclusion

The main benefit of an agreed-upon, shared-between-projects grid system is this. For an organisation, a great level of consistency can be achieved if widths in all of their sites come from one system (just as it helps if components for all of their sites come from one system).

Does that mean I think one grid system will fit all? No, adjustments are probably required sooner or later. That would mean new versions of ‘the grid system’ would get released. All projects within an organisation would be using ‘a’ version of ‘the grid system’. If this happens to be not the most recent version, the project team can decide whether to update to the latest version or not.

---

Originally posted as The role of grid systems in component-based front-end builds on Hidde's blog.

Reply via email

The next problem being solved for the web is not having the network: apps that work offline. I think when designing such apps, we should consider user intent, and in particular what a user intends to be available offline.

Web apps that work offline will download themselves into a user’s cache: their assets, their core app code, et cetera (see also: service worker). When the app itself is offlinified, the next choice is: which content should we make available offline? I think we should consider letting our users decide.

My newspaper app lets me download newspapers and requires no further connectivity once the download is completed. As a user, this allows me to download a newspaper to my tablet before I leave home, take a seat in a local train and start reading. Great for commuting. It lets me not worry about the network. In theory, my tablet might have 3G, or could connect to the train’s WiFi system. In reality, that would probably result in me struggling to get any data when the train is in a tunnel, or trying to battle the train WiFi’s registration page. The alternative, downloading the paper on my home WiFi, which I know works, is much better. For this to go smoothly, it is crucial the newspaper app has a ‘download for offline usage’ button.

A music subscription service I use, offers me the ability to have some music available offline. I use this feature a lot. If I need to catch the airport bus, I want to listen to that new album that came out. I know which. If I’m going for a long drive, I might make a playlist to listen to whilst driving in the UK’s beautiful, but not always well-networked country side. I create the playlist at home, and want it to be available on the go. So I think my music app with offline capability should let me choose what to make available offline. Spotify has a toggle that sets playlists to ‘available offline’, but it does not have UI to let a user download specific music (it behaves more or less like a hint). It will decide, based on how much connectivity and storage the device has. This makes sense, as often connectivity and storage are big uncertainties for the developer that builds the app, but it gets in the way of user intent.

Some apps choose to offlinify the last x items (eg a news site), or the content that the user has visited (eg an encyclopedia). The latter is a form of user intent, the former is unrelated to it. Naturally, depending on context, these can be a good strategies, too.

For the news and music player examples, honouring user intent can hugely improve a user’s experience. It may very well be possible to let the app decide what to offlinify when, but maybe your user just wants a particular thing to be offline. Today’s newspaper. Or, for that matter, last Tuesday’s issue, because their grandmother appears in it. This artist’s new album. This episode of that podcast. This A List Apart article.

Technically, it is far from trivial to do for a web app. Without going into too much detail: you don’t know if your user/their browser will have cleared their/its cache, or how much storage they have available.

In summary, I think if our app makes itself available for offline use, we should consider giving our users a choice in which content to make available offline.

---

Originally posted as Offline apps and user intent on Hidde's blog.

Reply via email

Web Components will allow web developers to create their own elements: custom elements. Last week I attended the Web Component panel and accessibility break-out at Edge Conference, and left both sessions full of questions. One was: what kind of custom elements do we need?

The idea of Web Components and specifically their custom elements, is that you no longer depend on the browser to provide you with elements: you can bring your own. Many blog posts about the subject emphasise how exciting this is. Yes, this is exciting new tech. It gives website owners lots of freedom, but also a big responsibility. I think Web Components have their use case for the web at large, but I can’t help but feeling that for many websites, it will be too costly to create and unnecessary to use custom elements.

Existing HTML elements come with benefits

Many of the existing, standardised HTML elements come with semantics, and browsers can do all kinds of smart things with them. Some examples:

• The <select> element lets a user pick one option from a list of options. Every browser can decide how to represent this best. My phone shows a fruit machine style thingy, an old-fashioned Windows style selector is shown on old Windows machines, and easy to recognise for users of such machines. A future version of Siri may be able to talk us through the options, in fact, some assistive technology already does this.
• The <video> element lets a developer point to a video, or indeed a couple of videos in different formats. The problem of how to play the video is then solved by the browser. Each browser chooses the best video player it can offer, and lets the user watch the video in it.

With existing HTML elements, the browser takes care of a lot of your accessibility, usability and design.

Custom elements come with responsibility

Contrary to most existing elements, a <custom-element> is much like a <div> : it has no meaning to the browser, so browsers have nothing built-in to deal with it. It doesn’t expose to the accessibility tree, has no usability or default appearance. Indeed, this is what a component creator has to take responsibility for themselves:

• accessibility / semantics
• usability
• what it looks like

For each platform.

The Gold Standard gives a great checklist for making Web Components “to be as predictable, flexible, reliable, and useful as the standard HTML elements”.

To increase a component’s accessibility, one could provide meaning through ARIA roles and properties. Or, if we use native elements within our components, we can have our cake and eat it too: when embedding existing elements, you would inherit their benefits. I have not been able to find a definite resource confirming this can be done.

It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

To provide usability, you would have to provide ways to interact with your element for whichever method your user chooses (or is forced to use by personal or indeed corporate circumstances). This is hard, because in most cases, as a website, you do not know a lot about the circumstances under which you are accessed. It is probably not easy to create a custom select or date picker that works as well as its native equivalent.

Design means designing for many different contexts: phones, watches, desktops, etc. And there are probably going to be contexts that we currently don’t know of: a future fridge with a web browser will probably know how to most suitably render a <select>, but it will not know how to deal with your <custom-datepicker> .

Chris Heilmann once said it makes sense to use what already works and build on top of that. I think this applies to custom elements, too. They would only have benefit, if they combine existing elements to bring something we need that does not exist yet.

Does building Web Components sound complex? In the Web Components panel, Google’s Alex Russell noted that “tooling will save you”. Tools can make it much easier to build better Web Components, for example by making them render both on the server and the client for progressive enhancement. But aren’t tools the problem?

Benefits of Web Components

Web Components are not just hard to build well, there are also many benefits to using them.

With Web Components, browsers (will) give website owners the power to bring their own elements. This gives a lot of freedom and is a big addition to the web as a platform. It is innovation we should welcome.

Web Components also bring developers the convenience of style/DOM encapsulation: if you work on a custom element’s CSS, you know it is only going to apply to that component.

Thirdly, a Web Component can be very portable: once you have created a <custom-element> and built all its behaviour and style, you can then use it where you like. As Peter Gasston noted in the EdgeConf Slack channel, “[They take] more effort to build, less effort to use”.

A fourth advantage of Web Components is for search engines: they can potentially start recognising widgets if they are used enough throughout the web, which would improve their search result listings.

An additional benefit of Web Components as a project is that it helps find missing platform APIs (a fascinating project by Domenic Denicola).

What kind of custom elements do we need?

In summary, custom elements can be good for the web as a platform, for developers and potentially for users, too. But building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap. So what kind of custom elements do we need?

Building custom elements that are accessible, well-designed and easy to use on all platforms, is not going to be easy, or cheap

Some say custom elements will be a bit like jQuery plug-ins: you need a carousel in your page, but instead of building it yourself, you peruse a third party carousel. You want your content to appear in tabs, so you go and use a third party tabs script. Instead of borrowing someone’s CSS and JS, you borrow their <fancy-carousel> or their <the-ultimate-awesome-tabs> , which have their styles and scripts nicely hidden inside their Shadow DOM. We should take care choosing only properly built ones. Also, we should be careful not to repeat the “just another plugin doing $x” mistakes.

I have the feeling that custom elements make most sense for huge companies that have many different websites and apps that have or should have shared elements. Google, who came up with Web Components, have a search engine, maps, Word processing tools, online storage, a social network, an operating system and many other products. It makes lots of sense for them to want to share many of their controls across their products. And they have plenty of designers and developers available to work on the usability, accessibility and design of such components, so it is more feasible for them to do it well (and even they do not have unlimited time and resources).

The same probably goes for big social network enterprises like Twitter and Facebook. They could create things like a Twitter timeline widget for people to embed in their site. Currently, I advise clients against using those, as they come with privacy and performance issues. If offered as a custom element, these issues might still be there, but now buried away in the Shadow DOM. Instead, offering the data as JSON, as Twitter used to do, would probably be more helpful for developers. But I guess that would add less value for Twitter’s shareholders.

Or perhaps media organisations like the BBC. Their video player seems a huge part of what they do, so they might have time to work on a custom element for it, that plays video exactly in the way they need it. For their own site(s), they have many, or perhaps for people to embed elsewhere.

Web Components could also bring a big benefit to people that create ‘apps’, websites where people go to do stuff, or maybe even games. They might need very specific controls, that do not exist in browsers yet.

How about smaller sites?

I’m not sure about the use case for smaller websites. One of the messages of Web Components seems to be that we can soon control style and behaviour of all the elements. But that’s not the full story: it is also very hard to do it well. I am afraid we will end up with lots of badly built components, if we do not tell the full story. What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard? Should we instead trust the capabilities of larger, Bootstrap-like projects, and use their components?

What if web agency clients start asking for cool, custom-designed and custom-behaving components, and the teams tasked with creating them do not have the budget to meet the Gold Standard?

Some have suggested Bootstrap and Foundation should start converting their components into Web Components, but I fail to see how that would solve a problem people actually have. It would be interesting to do it as a research type of thing, but to make them the main way to use Bootstrap or Foundation components just feels wrong.

I’m not convinced either, that every company should come up with custom elements for all the things, just because they can. Most elements can be built very well with existing HTML, without costing as much design and development time. I feel many web projects will hardly have a use case for utilising custom elements, or the budget for creating them. They would overcomplicate things. It still feels like eating a 5 course dinner when all you wanted was a salad.

I hope Web Components will get used by those companies that have genuine use cases for which the current set of HTML elements cannot provide. That will help push the web forward, and potentially add new ways of interacting with the platform. We are given the chance to add new elements, before WHATWG, W3C or browser vendors have the time to do so. Or the chance to create elements that would not be suitable to be part of the web standards, yet very useful to one organisation’s strategy. But before that can happen, what we need most is agreement amongst browser vendors.

So, what kind of Web Components do we need? Well-thought-through additions to the existing set of HTML elements, solving problems that aren’t solved by existing elements: yes, please. Many variations on improvements of existing elements like checkboxes and selects? As far as I am concerned, probably not. New elements built without considering accessibility or the huge diversity of browsing contexts? No, thanks.

Update 03/07/2015: Peter Gasston points out on Twitter that a lot of potential value is in the use cases we haven’t thought of yet. This is probably true, I may have to adjust my view when such cases arrive.

---

Originally posted as What kind of Web Components do we need? on Hidde's blog.

Reply via email

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, 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.

Jeremy Keith opening Responsive Day Out 3

Part 1: Alice Bartlett, Rachel Shillcock and Alla Kholmatova

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.

The business case for accessibility

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.

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.

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.

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.

Part 2: Peter Gasston, Jason Grigsby and Heydon Pickering

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.

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 element. Works everywhere but IE.
• HTML imports lets you import bits of HTML. Major problem: these imports block rendering (the imported file can link to stylesheets or scripts, which will need to be fetched). This may be replaced altogether by ES6 Modules.
• Custom elements let you have meaningful markup with custom properties. You create them in JS. The custom element names have a hyphen in them, because standard HTML elements will never have those, so browsers know which ones are custom. ES6 also offers a way to do this, possibly better, ES6 Classes.
• Shadow DOM: hide complex markup inside an element. This works by creating a shadow root (createShadowRoot()). Little agreement amongst browser vendors about other features than the createShadowRoot function. Still a lot to be defined.

Custom elements in Web Components bring a lot of responsibility, as they are empty in terms of accessibility, SEO and usability. With standard HTML elements, browsers have those things built in. With custom elements, they become the developer’s responsibility, Peter stressed. Potentially, there will be a lot of badly built Web Components once people start playing with them (like there are a lot of badly built jQuery plug-ins). The Gold Standard Peter mentioned may be a helpful checklist for how to build a Web Component and do it well. Peter also said we should use the UNIX philosophy: ‘every component does one job [and does it really well]’.

Peter said Web Components are good enough to be used now (but not for a business to depend on). He recommended using a library like Polymer for those who want to explore Web Components in more detail.

Responsive images

Jason Grigsby discussed Responsive Images, which has now shipped in most browsers and will work in others (IE and Safari) soon. His talk was about the why of responsive images. It has been designed to serve two use cases: resolution switching (best quality image for each resolution) and art direction (different image in different circumstances).

One of the puzzles around responsive images, Jason explained, is when to add image breakpoints. What dictates when to add an image breakpoint? Art direction might dictate breakpoints; this can be figured out and is mostly a design/art direction concern. Resolution might also dictate breakpoints, but this is much harder to figure out. How do we figure out how many breakpoints to use? In many companies, three breakpoints would to mind (phone-tablet-desktop), but that’s pretty artificial.

The ideal image width is the width it will have as it is displayed on the page. But in many responsive websites, images are sized with a percentage and can have many, many different widths, so often, some bytes will be ‘wasted’. So the question is: what is a sensible jump in file size? Maybe we should use performance budgets to make our choices about image resolutions? Important to note here, is that the larger the image, the larger the potential number of bytes wasted. That means we should have more breakpoints at larger sizes, as at larger sizes, differences are more expensive in bytes.

We can distinguish between methods that tell the browser exactly which image to use when, and methods that let the browser choose what is best. In most cases, Jason recommended, the latter is probably best: we just let the browser figure out which image to use.

Solving problems with CSS selectors

Heydon Pickering looked at making use of some powerful features of CSS (slides). He disagrees with those that say CSS is badly designed and should be recreated in JavaScript (‘pointless’) and showed in his talk how we can use the very design of CSS to our own benefit. CSS is indeed very well designed.

Most grid systems are not grid systems, they are grid prescriptions

Most grid systems out there, Heydon argued, aren’t much of a system. As they are not self-governing, they are more like grid prescriptions. Automatic systems can be done, using the power of CSS. Heydon suggested to look at CSS selectors as pattern matches. Matching containers full of content, we can look at how many bits of content we have, and let the browser come up with the best grid to display our content in. In other words: quantity queries. With nth-child selectors, Heydon showed how we can create a ‘divisibility grid’: looking at what your total amount of columns is divisible by, we can set column widths accordingly.

BEM-like conventions create order and control, but they throw out the baby with the bathwater by not using the cascade. The divisibility grid and quantity queries that Heydon create chaos, one might say, but as he rightly pointed out, this is in fact a ‘controllable chaos’.

Part 3: Jake Archibald, Ruth John and Zoe Mickley Gillenwater

The third segment started off with Jake Archibald, who talked about progressive enhancement in ‘apps’, followed by Ruth John who discussed a number of so-called Web APIs and lastly Zoe Mickley Gillenwater, with a talk about the many uses of flexbox on Booking.com.

Offline first

“A splash screen is an admission of failure”

Jake Archibald looked at progressive enhancement on the web, and showed how progressive enhancement and web apps are a false dichotomy. He emphasised it is indeed a great feature of the web that web pages show content as soon as they can, as opposed to last decade’s native apps, that often show a loading screen until everything you will ever need has loaded. On the web, we don’t need loading screens, yet some web apps have mimicked this behaviour. Jake argued this is a mistake and we can do better: ‘a splash screen is an admission of failure’. On the web, we can actually have users play level 1, even when the rest of the game is still loading in the background.

Jake Archibald making the case for progressive enhancement

Some web app slowness exists because all the required JavaScript is requested as one big lump, with a relatively big file size. Not a huge problem in ideal, fast WiFi situations, but quite a PITA for those with two bars of 3G on the go. Or for those accessing the web on what Jake referred to as Lie-Fi.

People may say all the JavaScript should download first, as it is a ‘web app’, and that this is how ‘web apps’ work, but that will not impress users. We can actually load the essential bits of JavaScript first and others later. Although this will decrease total loading time, it can hugely increase the time to first interaction. This is more important than overall load time: people will likely want to use your thing as soon as possible.

>A Service Worker can be put in place to make sure users can always access the cached version first, even when offline

After the first load, assets can be stored in cache. A Service Worker can be put in place to make sure users can always access the cached version first, even when offline. Whilst the cached version is being displayed, everything else else can be taken care of in the background, you can notify the user when it is ready. I felt this is a bit like offering your restaurant guests a table and some bread and wine, whilst you prepare their starter. You don’t have to let them stand outside until everything is ready, that would get them unnecessarily annoyed.

Service Workers, that allow for taking over the network management of the browser and thus for serving cache/offline first, can be used now. Not because they have support across all browsers ever made, but because they are pretty much an extra layer on top of your existing application. If your browser doesn’t understand this mechanism to get the app served from cache first, that’s okay, it will just be served a fresh version (as it would have been without a Service Worker). If it does, you can save your users from Lie-Fi.

Link: SVG OMG (load it, turn WiFi off, load it again, it still works!)

Web APIs

Ruth John talked us through various different Web APIs, or as she likes to call them: client side web APIs. She showed interesting demoes of Geolocation, which gives access to a user’s location if they give permission, including a ‘watch’ function that can update so that you could build a sat nav application, Web Animation, which offers the animation properties from CSS in JavaScript, the Web Audio API, that lets one manipulate audio amongst other things, and finally the Ambient Light API, that gives us the tools to do useful little improvements for our users.

Flexbox

Zoe Mickley Gillenwater works at hotel booking website Booking.com, which is a hugely flexible website, as it is served in many different languages and on many different screen sizes and browsers.

When designing for the web, Zoe explained, we can used fixed units like px, or relative units, like rem or vw. Relative units can be a useful ‘best guess’, let you be close to an ideal, and work in many different circumstances. Even better than flexible units, is designing without units at all. Flexbox allows you to do exactly this. It lets you tell the browser an element’s starting size and whether it can grow/shrink, and lets the browser figure out the math.

[Flexbox] does responsive lay-outs without media queries

Flexbox, Zoe showed, is great for improving whitespace and wrapping for better coherency in lay-out. It often does this better than floats, inline-block or table-cell, but can (and probably should) be used in conjunction with those, as they provide a usable feedback. It is also great for reordering: with its ‘order’ property, you can achieve visual improvements by setting an element to display in another place than your source order. Lastly, it does responsive lay-outs without media queries, as it will display within your constraints and figure out its ‘breakpoints’ all by itself.

Zoe pointed out that the interesting difference between flexbox and other CSS features, is not really code, but our way of thinking about lay-out. It requires a bit of a mental shift. Responsiveness, Zoe concluded, is not binary, it is a continuum, and flexbox can help making your site more responsive. You can make lots of small minor changes to your site, each of which can make it more flexible. Browsers will make use of those improvements if they understand them, devices will make use of them if they are smaller or bigger than usual (most of them are, but all in different ways).

Part 4: Rosie Campbell, Lyza Gardner and Aaron Gustafson

In the final part, Rosie Campbell looked at the future of web design beyond the screens as we know them, Lyza Gardner pleaded for generalists in the web industry and Aaron Gustafson presented his idea of what we should expect next.

Beyond the screen

Rosie Campbell from the BBC talked us through some of the experiments she was involved with at the BBC Research lab. She noted that screens will only get weirder, and urged us to think about designing for such screens that don’t even exist yet. How? Stay agnostic to underlying hardware, she recommended. And reconsider assumptions: we are used to designing with rectangles, but future screens may be round, or indeed have completely different sizes. We should not be afraid of constraints, but embrace them as they can fuel creativity.

Skillsets

Lyza Gardner talked about how the web designer/developer job has changed in recent years, and what that does to us as people that just try to work in the web industry.

The web used to be much simpler, Lyza explained. In the beginning there was no JavaScript, there were no stylesheets, even images hardly had browser support. These constraints made working on the web interesting. This has changed hugely, as we now have a daily influx of new frameworks, tools and methodologies to learn about, consider adopting and perhaps specialise in. Because there is now so much information about so many different things we can do with the web, working on the web has become quite complex. There is more than anyone can possibly keep up with. This, Lyza said, can make us feel down and unsure.

[Generalists] think and talk about the web with nuance

The web industry celebrates specialists, we adore single subject rock stars, but we should be careful not to dismiss people that don’t specialise, but generalise. Generalists, unlike specialists, cannot show off their specialisms on their CV, and may not be great at fizzbuzz, but they have other things to offer. They can think and talk about the web with nuance. They synthesise and when combining synthesis with their skills, show how valuable they are. When given a problem they have not seen before, they can synthesise and do it. Generalists are beginners over and over again.

We should be generalists, Lyza concluded, we should cultivate wisdom and share it.

Where do we go from here?

The day was concluded by Aaron Gustafson, who looked at what’s next. The A List Apart article Responsive web design, Aaron said, was the first to provide a concrete example of the principles of A Dao of Web Design (speaking of how valuable generalists are…). That article goes into the flexible nature of information on the web. Content created once, accessible anywhere, as it was envisioned by Tim Berners-Lee.

Accessibility is core to the web, and it goes hand in hand with the flexible approach John Allsopp and Ethan Marcotte describe in their articles.

Accessibility is core to the web, and it goes hand in hand with the flexible approach John Allsopp and Ethan Marcotte describe in their articles. Don’t make assumptions about how people want to access your website, just let them access it in any way they want, by providing solid mark-up of well structured content.

Accessible websites have a benefit in the future of the web. There will be more controls and inputs, like gaze and eye/facial tracking. Voice will play a bigger role, too. You may have provided CSS with your content to display it beautifully across devices, but those users using voice will not see that. They will just be listening, so it is of utmost importance that your mark-up is well structured and the source order makes sense. That it is accessible.

Responsive web design, Aaron concluded, is all about accessibility. It is about making things accessible in the best possible way.

Wrap-up

As may have become clear from my notes above, Responsive Day Out 3 was a day full of variety. I had the feeling it could have easily been called Web Day Out, and I guess that makes sense, as responsive web design has naturally grown to be a pleonasm in the past few years.

I found a couple of common themes throughout the talks:

• Let the browser figure it out. Throw multiple image types/resolutions at it, and let the browser decide which one to display, as Jason explained. Or like Zoe demonstrated, tell the browser roughly how you want your element to be with flexbox, and let the browser figure out the maths. Give it some relatively simple CSS instructions, and let it grid your content for you, as Heydon did.
• Soon, we will be given more responsibilities. As Peter noted, Web Components will let us define our own components, which makes us responsible for setting up their usability and accessibility. Service Workers, as Jake showed, put us in control of network handling, so that we can decide how to handle requests (and respond to them with offline/cached content first). If we use Web Components or Service Workers, we explicitly choose not to let the browser figure it out, and provide our own algorithms.
• Responsive web design is all about accessibility. Although it is hard to make a business case for it, accessibility is very important, as it is a core concept of the web, as Aaron mentioned, and, being mostly device-agnostic, our best bet at future proofing content for screens that don’t even exist yet, as Rosie pointed out.
• Make things as flexible as you can. Good responsive design makes things very flexible. Flexbox and the non-binary improvements it creates, as Zoe discussed, make sure things work in many places at the same time.

---

Originally posted as Responsive day out 3: the final breakpoint on Hidde's blog.

Reply via email

At this month’s Accessible Bristol, Léonie Watson talked about improving accessibility by making use of WAI-ARIA in HTML, JavaScript, SVG and Web Components.

The talk started with the distinction between the DOM tree, which I assume all front-end developers will have heard of, and the accessibility tree. Of the accessibility tree, I had a vague idea intuitively, but, to be honest, I did not know it literally exists.

The accessibility tree and the DOM tree are parallel structures. Roughly speaking the accessibility tree is a subset of the DOM tree.
— W3C on tree types

The accessibility tree contains ‘accessibility objects’, which are based on DOM elements. But, and this is the important bit, only on those DOM elements that expose something. Properties, relationships or features are examples of things that DOM elements can expose. Some elements expose something by default, like <button>s, others, like <span> , don’t.

Every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’

This could perhaps lead us to a new approach to building accessible web pages: every time you add HTML to a page, think ‘what does this expose to the accessibility tree?’.

Exposing properties, relationships, features and states to the accessibility tree

An example:

<label for="foo">Label</label>
<input type="checkbox" id="foo" />

In this example, various things are being exposed: the property that ‘Label’ is a label, the relationship that it is a label for the checkbox foo, the feature of checkability and the state of the checkbox (checked or unchecked). All this info is added into the accessibility tree.

Exposing to the accessibility tree benefits your users, and it comes for free with the above HTML elements. It is simply built-in to most browsers, and as a developer, there is no need to add anything else to it.

Non-exposure and how to fix it

There are other elements, like and <div> that are considered neutral in meaning, i.e. they don’t expose anything. With CSS and JavaScript, it is possible to explain what they do, by adding styling and behaviour.

<!-- this is not a good idea -->
<span class="button">I look like a button</span>

With CSS and JavaScript, it can be made to look and behave like a button (and many front-end frameworks do). But these looks and behaviours can only be accessed by some of your users. It does not expose nearly enough. As it is still a <span> element, browsers will assume its meaning is neutral, and nothing is exposed to the accessibility tree.

Léonie explained that this can be fixed by complementing our non-exposing mark-up manually, using role and other ARIA attributes, and the tabindex attribute.

<!-- not great, but at least it exposes to the accessibility tree -->
<span class="button" role="button">I am a bit more button</span>

For more examples of which ARIA attributes exist and how they can be used, I must refer you to elsewhere on the internet — a lot has been written about the subject.

Exposing from SVG

With SVG becoming more and more popular for all kinds of uses, it is good to know that ARIA can be used in SVG. SVG 1.1 does not support it officially, but SVG 2.0, that is being worked on at the moment, will have it built-in.

SVG elements do not have a lot of means to expose what they are in a non-visual way (besides <title> and @), and this can be improved with ARIA labels. Léonie gave some examples, and wrote a blog post about SVG accessibility which I can highly recommend.

Exposing from Web Components

Web Components, without going into too much detail, are custom HTML elements that can be created from JavaScript. For example, if <button> does not suit your use-case, you can create a <my-custom-button> element.

At the moment, there are two ways of new element creation:

• an element based on an existing element (i.e. is like , but…). It inherits its properties/roles from the existing element if possible
• a completely new element. This inherits no properties/roles, so those will have to be added by developer that creates the element.

The first method was recently nominated to be dropped from the specification (see also Bruce Lawson’s article about why he considers this in violation with HTML’s priority of constituencies, as well as the many comments for both sides of the debate).

Again, like <span> s used as buttons and with SVG, these custom elements, especially those not inherited from existing elements, scream for more properties and relations to be exposed to the accessibility tree. Some more info on how to do that in the Semantics section of the spec.

“Code like you give a damn”

Léonie ended her talk with a positive note: to build accessible websites, there is no need to compromise on functionality or design, as long as you “code like you give a damn”. This showed from her examples: many elements, like <button> expose to the accessibility trees, they come with some free accessibility features. And even if you use elements that do not come with built-in accessibility features, you can still use ARIA to expose useful information about them to the accessibility tree.

Personally, I think the best strategy is to always use elements what they are used for (e.g. I would prefer using a <button type="button"> for a button to using a supplemented with ARIA). In other words: I think it would be best to write meaningful HTML where possible, and resort to ARIA only to improve those things that don’t already have meaning (like SVG, Web Components or even the <span> s outputted by the front-end framework you may be using).

---

Originally posted as The accessibility tree on Hidde's blog.

Reply via email