Custom Elements present a fantastic opportunity for us to improve accessibility on the web.

To be accessible, elements need to work across multiple devices with varying screen-sizes and different kinds of input. Moreover, your elements should be usable by the broadest group of users, including those with disabilities.

Web Components (WC) are a new set of web platform features that enable developers to build applications in a declarative, composable way. The following is an initial list of best practices we advocate component authors consider to ensure their elements are good citizens in the Web Component ecosystem.

Web Components are a hot topic now. Creating widgets on the web that are part of the browser’s rendering flow is amazing. So is inheriting from and enhancing existing ones. Don’t like how a SELECT looks or works? Get it and override what you don’t like. With the web consumed on mobile devices performance is the main goal. Anything we can do to save on battery consumption and to keep interfaces responsive without being sluggish is a good thing to do.

It all started 7 months ago in October, 2013 with a new organization on GitHub called WebComponentsOrg. Googlers from the Polymer/Chrome team, along with some great folks from Mozilla’s X-Tag/Brick, as well as other Web Components community members (like me) had been cooking up a vision for a simple, neutral site/community devoted to encouraging good best practices for Web Components.

Naming is always a challenging task when developing a component. We can create truly complex pieces of code but we still have a hard time to name a simple variable. The same is true for naming custom elements and we're here today to help you with that.

Building modern web applications requires a lot of tooling. This includes preprocessors, JavaScript frameworks, testing tools and a whole lot more. And as the complexities of these apps increases, so does the breadth of tooling and services needed to manage them. Wouldn't it be great if some things were simplified?