This application is a living style guide, generated from KSS documented styles...with an accessibility twist. See a live demo of the style guide.
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? What accessible pieces should we even include? Which pieces are easy wins vs. impossible juggernauts? How do we implement inclusive design and development when a project does not have a lot of time or budget to include that piece?
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 comes with pre-populated accessible components that include helpful links to related tools, articles, and WCAG guidelines to make your site more inclusive. These components also serve as a guide for both HTML markup and SCSS/CSS code, to inform designers, front-end and back-end developers at every stage of the website’s creation.
- Use it as a reference.
- Use it as inspiration.
- Use it as a base style guide.
- Use it for creating base components.
- Use it as a base for an accessible theme.
- Contribute to the tool and make it better.
- Fork it and give your own spin to it.
Really? What can't you do with it is an easier question?
This has a KSS node base, so learn a bit about how KSS node works
To make local changes to components, do the following:
- Fork the project
- Navigate to the project root
nvm install stable(only need to do once - see the NVM project for troubleshooting)nvm use stablenpm install(only need to do once)git checkout -b my-new-feature(create your feature branch)- Make changes
npm run gulp(this will run all the gulp commands)git commit -A(adds all changes)git commit -m 'Add some feature'(commit your changes)git push origin my-new-feature(push to the branch)- Create new Pull Request
This will run all the gulp commands including the style guide update. If you want to contribute back, please do so! This is a great Git resource if you need to brush-up on your skills (all levels)
Maybe you are a total beginner and wondering where to start? That's cool too...welcome! Learning accessibility can feel a bit like drinking out of a firehose, so here are some tips to follow on your journey toward accessibility:
- Tip #1: Don’t Freak Out. There is a ton of information out there about website accessibility. No one expects you to know everything about everything. It’s ok to say you don’t know something. Which brings me to my next rule…
- Tip #2: Learn a Few Things. Read an article, watch a video, attend a webinar, chat with someone on twitter. If you focus on one aspect of accessibility at a time, you will not get overwhelmed and you will retain the information better.
- Tip #3: Build from the Ground Up. If you have the opportunity, build accessibility into the beginning of a project. It will be more difficult, more timely and thus more expensive to retrofit your site for accessibility after the site is complete.
- Tip #4: Use the Right Tools. There are lots of accessibility tools that wonderful people spent lots of time creating, so use them. Use tools during the build process (ex. using Color Safe to check color combos) and after the site is finished (ex. using WAVE to evaluate accessibility errors and alerts, etc)
- Tip #5: Try, Try Again. Keep in mind that even adding one or two accessible pieces to a website is moving in the right direction. The next site might have four or five pieces. “Rome wasn’t built in a day” and neither are accessible websites.