Just announced: Level Access and eSSENTIAL Accessibility agree to merge! Read more.

Early last week, during two beautiful late summer days here in Europe, I attended Google’s Polymer Summit 2017, with hundreds of other developers from across the globe.Use The Platform Banner

This year, the conference took place at the stunning, massive and “meget trendy” (as they say in Danish) Lokomotivværkstedet (the old railway workshop) in Copenhagen, Denmark. Google provided two full days of talks, codelabs, and breakout sessions all from the folks from the Polymer team, Googlers, or major companies who use Polymer and Web Components.

This is the third consecutive Polymer Summit run by Google, with previous locations in Amsterdam and London, and the biggest.  But, what, no U.S. locations I hear you say??? Well, I chatted with one or two conference attendees about Google’s choice of three European locations in a row, and the speculation was that although the popularity of Google’s Polymer library is growing in the U.S., it’s still nowhere near as popular as other UI-centric technologies like React.js.

To date, such UI-centric libraries, tools and frameworks available have been designed to polyfill over the gaps in the web platform – providing abstractions which develops can then more easily program against.

But, is that set to change?  

Thanks to new web platform native functionality, many of the needs previously addressed by libraries, tools and frameworks are now met by the platform itself – a fact that was reflected time and time again in the number of questioning comments you’d hear from participants during breaks about their continued use of large monolithic JavaScript UI frameworks / libraries.

A take-away for me was that there seemed to be a growing appetite for something different… In two words, “Web Components.”

Web Components, as you probably know, are a set of HTML / DOM features being developed through W3C that allow for the creation of reusable widgets or components in web documents and web applications, effectively bringing component-based software engineering to the Web.

In a nutshell, Web Components are designed to encapsulate their styles / functionality, so they can be easily:

  • included in any host web pages without consequence;
  • maintained / updated separately from any host web pages; and can use different external libraries from the host web page or other web components.

They have already begun to be adopted by mega-sites like Youtube.com, recently being re-built from web components, together with Netflix.

So, if Web Components is the destination, then the Polymer project is like a special tunnel through the hill (rather than mountain) to the land of Web Components, which allows us to see and use Web Components before we finally arrive there.  Polymer, if successful, will simply dissolve at the end of its caterpillar life leaving the beautiful web component butterfly in its place.

So what is Polymer?

Polymer (now Version 2.0, with “beta” 3.0 launching at the Summit) is an open-source JavaScript library developed by Google developers and contributors on GitHub. It enables the creation of custom reusable HTML elements, all based on latest standard Web Components APIs (with polyfills).

Polymer is a town-cryer and torch-bearer rolled into a single project:

  • Firstly, informing the crowds of developers in different UI-framework bubbles that JavaScript API’s have now come along way, so you don’t necessarily need your large monolithic JavaScript UI frameworks / libraries; and
  • Secondly, directing a way to what really useful web components might be.

The Polymer team’s slogan “#use the platform” (in effect, the native JavaScript functionality available in the web browser) is very apt, as levering the platform’s inherent power for heavy lifting means elements built with the Polymer library, according to Google, are “blazing fast”.

Polymer is still a library, however, one that has been designed to embrace the strengths of the platform itself, rather than recreate these strengths in another manner.

Level Access of course attended the conference due to its interest in the accessibility of bleeding edge user-interfaces, and the tools used to create them.  In this, Polymer does not disappoint (with a few wrinkles that I’m sure will be ironed out).

photo of crowd at a presentationGoogle has seemingly tried hard to include accessibility features in Polymer from an early point (such as keyboard support for custom elements).  And, I should also make a special mention of Google’s Polymer Team members who each went the extra mile to ensure that accessibility was mentioned in their talks (well done!); and also to Rob D
obson from the Polymer Team who has created some very useful YouTube videos on Polymer Accessibility.

In summary, this conference indicated to me a clear weather change in the direction of travel of front-end UI development.  It also showcased a number of things which – with a bit of imagination – indicate how the future might look.  I was especially interested in a talk by Monica Dinculescu (https://www.youtube.com/watch?v=otcmcNY-3pk) from the Google Polymer team who demoed “Wizzywid” (https://polymerlabs.github.io/wizzywid/) – an early version of a tool that can be used to visually build a UI using web components.  This “WizzyWid” tool currently uses Google’s Web Component Library – but, if you think about it – loading new libraries and mixing and matching components is all now a possibility…

In upcoming blog posts, we’ll be looking to show people:

  • How to use the built in accessibility features in Polymer;
  • How accessibility works in a “time to first interaction TTI paradigm” and
  • How to test that accessibility features have been correctly implemented in Polymer.

Alistair Garrison is the Director of Accessibility Research at Level Access. As a passionate and long-time champion of web accessibility, he has spent the majority of his career devoted to the specification and development of web accessibility evaluation methods, applications, and consultancy services to support inherent accessibility in the enterprise. Over the past few years, he has become progressively more focused on QA tool-supported accessibility testing; and how best to integrate it into Agile development processes.  Alistair has been an invited expert for W3C/WAI for many years, and has helped to create several W3C / WAI documents (including the WCAG 2.0 Evaluation Methodology, and WCAG 2.0 Techniques). Alistair currently participates in W3C/WAI’s WCAG 2.0 Accessibility Conformance Testing Task Force.