Responsibilities

Some of the information on this page may be out-of-date. If you have any questions about content on this site, please contact digital-accessibility@berkeley.edu.


If you work on or manage a website or web-based product at UC Berkeley, here are some recommended guidelines and examples for complying with UC's policy on accessibility.

Website and Content Owners:

  • Identify your audience. Is your website used by all or most students to apply for a service from Berkeley? If so, an inaccessible website or product may not be usable by any students with disabilities, putting the campus at risk for a lawsuit. If your website has only a small campus audience, then less risk is involved.
  • Educate your team and allocate time for accessibility. Make sure your team members are aware of accessibility testing tools and testing resources, and give them enough time to perform tests when working on website projects.
  • Test your site frequently for accessibility, even if it is not a new site. You do not have to have a new website in order to evaluate for accessibility and implement fixes. There are many free tools available for testing accessibility.
  • Include a way for users with disabilities to communicate any problems with your site. Keep the communication lines open, and make it simple for all visitors to find contact information for your site.

Web Developers:

  • Choose accessible technologies. Whether you are using Drupal, Wordpress, Rails, etc., be sure to consult external documentation about accessibility and follow those guidelines when building your website or product. Avoid technologies that don't have sufficient documentation for accessibility.
  • Include accessibility in your process as early as possible. If you include accessibility from beginning to end, you will have a stronger product that will require fewer fixes and tests after the bulk of your work is completed.
  • Perform frequent tests. There are many free tools available for testing accessibility that can be used throughout the development process. Once you have a prototype and some features in place, test your site for accessibility.

Buyers:

  • Include accessibility language in RFPs (Request for Proposal). When putting together an RFP for an external vendor, make sure that accessibility is included in your requirements for the product, and include accessibility scenarios in product demos.
  • Understand that it will cost less money to require accessibility up front, rather than trying to fix an inaccessible product after it has been purchased. This will help when working with certain budget restraints. See the UCOP guidelines for procurement for more helpful information.

Users of Technology:

  • Understand your rights. Request an ergonomic evaluation and consult other available end-user resources, and learn about assistive technologies if you have a disability.
  • If you cannot use a website or product, request assistance.