Inclusive Development: Using Style Guides to Improve Website Accessibility
What exactly is the role of a Front-end developer?
What exactly does it mean to be a 'front-end developer'? From company to company? From website to website? Really, from day to day? Does your colleague actually do the same job as you? For example, some days I’m working in InDesign or Photoshop all day, the next I’m writing jQuery or building theme components. The very next day I am writing a blog post, prepping for a presentation, or doing research on the latest trends.
We wear a lot of hats as front-end developers. Depending on the client or company you work for, you may be the designer, UX/UI specialist, site-builder, QA tester, and developer all rolled into one. How can we possibly add the accessibility hat on top of all that...especially when a project does not have a lot of time or budget to include that piece?
What, Who, and Why of Website Accessibility
What is website accessibility?
“Web accessibility means that people with disabilities can use the Web. More specifically, web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the web and that they can contribute to the web. -" Web Accessibility Initiative (WAI)
Basically, it’s making websites more inclusive to all people.
Who is in need of accessible sites?
Everyone! Over 57 million Americans (~20% of the US population) identifies as having some type of disability. These range from severe disabilities to temporary disabilities but does not even count the percentage of the population that either does not identify as having a disability or those populations that could benefit from accessible sites, such as English as a second language and the aging populations. The number of people actually needing accessible websites is far greater than the population who identifies as disabled.
Why should you care about accessibility?
It is the right thing to do - it is important that your website is ‘perceivable’, ‘operable’, ‘understandable’, and ‘robust’(POUR) - all successful criteria for a user experience that provides optimal usability for everyone.
It is a smart business move - The population of the states of California and New York combined is around 57 million users, the same number as those who identify as being disabled. Would you ever create a website that would exclude these two large states? Does that make any sense? Optimizing your website for accessibility opens your site to a wider audience (potential 20%+ increase users), plus it is good for SEO/search bots/Google ranking, etc.
It is the law - Government-funded programs/schools, airlines, and nonprofits are required to follow accessibility guidelines, while private companies/organizations just hope they do not get sued. Earlier this year the Information and Communication Technology (ICT) passed a ruling to update the old 508 rules to be more in line with current WCAG 2.0 guidelines. This ruling is for the public sector, but it is setting up the possibly of regulations in the private sector as well.
What is Inclusive Development?
Now that we have defined what being a front-end developer is (that it is variable) and what accessibility is (sort of nebulous, but we know it is important), but what is inclusive development? Is that just a fancy word for “developing with accessibility in mind”? Yes and no…
So the term Inclusive Design is not a new one. It is a phrase that has been around since 2005. It’s defined as: “The design of mainstream products and/or services that are accessible to, and usable by, as many people as reasonably possible ... without the need for special adaptation or specialized design.”
Inclusive development is really taking that next step and adhering to inclusive design practices. It is a way of rethinking development in a way that adds value to all users, not just accessibility to some users. It is a shift in the way you approach your thinking about development. So basically, if you target your website for the 25% of your users that have severe difficulties, then it will cover all the additional users with little to no difficulties. Adaptive technologies (AT) help cover the severely disabled users with specialized products. Inclusive development means making something valuable, not just accessible, to as many people as we can. It is about putting “Accessibility First.”
At this point, you might be thinking…design terms, accessible philosophies, actually thinking about my code…I did not sign up for this! Well, I would argue that the way you might feel about accessibility today is much like how we felt when we heard about the “Mobile First” approach way back in 2009. If you remember, when the mobile first approach appeared (where we design/develop for smaller screens first then add more features and content for larger screens), it was a crazy and overwhelming shift in thinking and front-end workflows. Now it is just part of our daily lives as front-end developers. I am not even sure I could make a site that wasn't responsive at this point.
Now it is 2017 and “Accessibility First” may seem just as daunting and impossible...there is so much to know, so many different ideas of what accessibility means, new rules, new tools, etc. But if you have the right tools and attitude, there is hope!
Why use Component Driven Development?
To recap, we are front-end developers and we care about accessibility, maybe we even think about accessibility first…now what? How does component driven development play a role in all of this?
I bet a lot of people by now have used component driven development in their front-end workflow process. Even if you have not formally heard the term or use the tools, I am betting you are already doing it to some degree already…it is about breaking a large site down into manageable pieces. Much like building a house (out of legos or real materials), you need to build one piece of your house at a time…first the foundation, then the skeleton structure, walls, windows, roof, and everything in between. Component driven development tools allow us to do this, but for websites.
Component driven development helps break the site down into manageable components, so there is less development time with these reusable components. It allows front-end and back-end developers to work simultaneously. And clients love it because they can preview the build process and can use living style guide as a reference after the site has launched.
Front-end Development + Accessibility + Inclusive Development + Components = A11Y Style Guide
One of the first questions I asked at the beginning of this article is: how do we add accessibility to a project does not have a lot of time or budget to include that piece? Well, one way we can tackle these issues is by using an accessible component driven approach. By thinking about inclusiveness from the start, we can get a head start on accessibility while still building the required site components.
The A11Y style guide was formed out of front-end development workflows, aided by the component driven development tool KSS node, and fueled by the conviction that everyone deserves to be able to use and contribute back to the wonderfully wacky web.
The A11Y style guide is ultimately a style guide that comes with pre-populated accessible components that include helpful links to related tools, articles, and WCAG guidelines to make your site more inclusive. You can use it as a reference, as a base for your own style guide or accessible components. You may even decide to create a new accessible theme based on the guides.
The concept of the A11Y style guide is really simple. I did not reinvent the wheel with this project. This tool builds on all the wonderful work that is already being done in the world of accessibility and makes that existing knowledge base more applicable to real-world scenarios in a condensed manner. I lovingly think of it as the “CliffsNotes” of accessibility or a nicer term may be “accessible pattern library” for front-end developers.
But by using a reusable, accessible, component driven approach and thinking about inclusiveness from the start, we can get a head start on building accessible websites. So ultimately you and your clients save time and money, plus your site is a little more inclusive…what’s not to love?
6 Design Alternatives to Avoid Slideshows | Blog
Accessibility Laws and Guidelines | Webinar
5 Ways to Sneak Accessibility into your Next Design | Blog
Building Accessibility into a Website from the Start | Blog