First up a big shout out to Joe Orozco and the Virginia chapter of the National Foundation for the Blind for helping us vet our process here. Your work is inspirational and has helped drive our mission of greater accessibility in measurable ways - below is a description of one.
Accessibility has always been a central tenet in our web development process at the library. Working in a health system encourages these goals, and our administration addresses this mission by providing time to research the latest strategies in content accessibility, as well as opportunities to implement what we learn in the real world.
These days many front-end surveys are accessible - many people at UVa use our Qualitrics framework - and they do a great job of acknowledging the pros and cons of different survey widgets. When we took on this project, however, we wanted to reach a little further and focus on making the course creation process as accessible as possible.
When a front end accessibility becomes an administrative accessibility headache
This is a picture of an inaccessible survey widget where a Likert Quality scale is used in a grid format. While the labels are clear on the top, they are not easily identifiable above each radio button, making them less accessible than other available survey widgets
Resolving this accessibility is pretty simple - take the grid-styled group question and create a unique question for each row... this is very simple, and using webform we can even clone the questions. Not too bad for the course administrator...
One of the detractions of webform, however, is the reliance on text entry for each select option. While this is useful because it gives a clear and accessible link for each question it can require a lot of repetitive typing - introducing room for error and making the administrative less accessible than we wanted.
This is a picture of the text that creates a select list in the drupal webform module. Each option has to be specified, and a machine name has to be created also... technically speaking it's accessible, however if you're creating a long survey and have to do this every time it's not very attractive. It's also just not great best practices since it's not clear how analytics would connect the dots for reporting
By adding another module - known as values - we now have these drop-down lists of choices that pre-fill the select options and simplify user interface.
Here's a picture of the administrative side of the values module in action - the drop down list provides pre-created select option lists that have their own administrative interface for managing, translating etc...
Using the values module is straightforward. Install the module how you would any other module (drush, composer, or manually), and turn on the sub-module for webforms. Once enabled the instructions on the page for values are clear - you'll need to go to the values section and add select options
This is an image of the values page. On the left column is a description of the select list group and on the right side are the options to edit, delete, or export your lists. Lists may also be imported. Here is a look at the translations available for this module as well https://localize.drupal.org/translate/projects/values
Drupal is a large framework, and some of the key tools are not as simple as one might hope for out of the box, however with no programming experience and a bit of digging around in google there are a lot of opportunities to leverage the framework. Improving small details of content creation helps ensure that accessibility is introduced not as an afterthought tied to some administrative checkbox, but rather as a starting point and core point from which other aspects may develop.
Claude Moore Health Sciences Library
1350 Jefferson Park Avenue P.O. Box 800722
Charlottesville, VA 22908 (Directions)
Contact UsStaff Directory(434) 924-5444Feedback
© 2023 by the Rector and Visitors of the University of VirginiaCopyright & Privacy