Core Skills for Web Developers

Estimated reading time: ( words)

Summary: Web accessibility is not a compromise. Web accessibility is an opportunity to become better at what you do. Will you?

Web Content Accessibility Guidelines (WCAG) 2.0, level AA, serves as the web accessibility standard for the University of Minnesota.

Accessible web development: what does it mean?

From a coding perspective, the goal is to code a website or web application that, at minimum, meets Web Content Accessibility Guidelines (WCAG) 2.0 AA standards. Your website or web application should follow these four guiding principles of accessible technology:

  • Perceivable - Users must be able to find every item using one of their senses.
  • Operable - Users must be able to interact with the site and all of its features.
  • Understandable - Content and functionality should be easy to follow.
  • Robust - Sites should work with various technologies and consider future technologies.

More information about the POUR guiding principles (WebAIM).

Make accessibility part of the coding process

Coding for web accessibility can be intimidating. At first glance, the WCAG standards can seem confusing and complicated. In addition, it can be daunting to have to learn how to use different adaptive technologies like screen readers.

Fortunately, you can make the websites and applications you code accessible--or mostly accessible--by focusing on learning skills in just a handful of areas (see the "In This Section" panel on this page). 

While always encouraged, testing your website or web application using a screen reader is not always necessary.

Lastly, a network of developers on campus can help: Ask your stickiest questions with either the Code People group or Web People group.

It isn't all about screen readers

We're coding to make information accessible by people who use any and all types of adapative technologies. Screen readers are but one example. Learn more about the different types of adaptive technologies, and consider the effect of accessible code on all of your potential users.

Write accessible code from the beginning

Accessibility should be incorporated as soon as you start to write code. Trying to retrofit your code for accessibility later on can lead to:

  • Missed deadlines
  • Never actually "getting around to it"
  • Pressure to skip accessibility
  • Re-coding and/or functionality redesign at the end of the project
  • Missed accessibility features

While there is a learning curve at the beginning, it takes about the same amount of time to write accessible code as it does to write inaccessible code.

Test often

You should check for web accessibility frequently during development. View your websites and web apps in a browser to ensure they display and function correctly.

Browser plug-ins and tools can help you check for accessibility as you code. 

Build in reminders

In the messy process to get a website or web application coded, it is easy to forget or forgo accessibility. We recommend these strategies:

Accessibility doesn't compromise design

There is the misconception that making a website or web application accessible requires developers to not use more advanced user interface components. This is rarely true. Many modern user interface components are either accessible or can easily be modified to be accessible.

In addition, there is the misconception that using advanced CSS and/or JavaScript will make a website or web application inaccessible. This is also a myth. 

Most web devices, including adaptive technologies including screen readers, correctly execute JavaScript and CSS. In fact, CSS and/or JavaScript often are used to make a website or web application more accessible.

Start with an accessible template

To kickstart your project, copy from an existing template or similar project. Ensure that the items you start with are already accessible. Fortunately, frameworks like Bootstrap are starting to incorporate accessibility into their code, and more importantly, into their examples.

Many examples on the Web claim to be accessible but may not be, or they may follow a different, less rigorous standard. Always check the accessibility of code snippets, templates, and frameworks before you implement one into your project. Check out the U of M accessibility project on GitHub for more.

Did you find what you were looking for?