Not everything applies to you

These trainings appear to be written for web designers and web developers, we well as content creators. Some things that are mentioned (and that you may be quizzed about) are not even remotely relevant to the work that you will do (and frankly, have permission to do!) Things like JavaScript, JavaScript alerts, ARIA, Live elements, :hover and :focus states, HTML elements and attributes are all things that are outside the scope of what you can do on the Library website. (Kyle and I handle these things.) It’s still useful to know a little about how websites become accessible under the hood, and, of course, they will quiz you about them.

Personas are design documents

In design, we often use “archetypal users” to stand in for particular user groups. These archetypes are called “personas.” When they introduce the different personas to you throughout this section, they are showing you a design document, but they never really explain what it is. Personas are helpful for designers because you can embody a specific group of users–like undergraduate humanities majors–in a single person that you can refer to by name. We use a few personas here at the GVSU University Libraries, which you can find in the web style guide.

When they talk about “semantics,” they mean the structure of the text.

Think of writing in Microsoft Word. If you want to make a heading, you have two options. You can highlight the text and making it bigger and bold, and it will look like a heading. But the computer just sees bold text that is bigger. It only knows about the visual changes you’ve made, not the meaning of a heading. For that you need to select a heading level from the styles pane. The heading level will change the font size and weight, too, but the computer will also understand that in addition to being visually different, the text is also a section heading. The same is true on the web in HTML. Use the styles pane to select heading levels rather than just making text bold and bigger. (Font styles are not communicated to users of screen readers.)

You can't change colors

In LibGuides and the CMS, you don’t have the option to change colors specifically, because of color contrast issues. It’s good to know about color contrast and color blindness issues, especially if you embedding images of logos for vendors or publishers. But you probably won’t have to test colors yourself, Kyle and I and the Web Team have already tested all the color combinations on the website.

If you are worried your text is too complex, you can use a readability analyzer to review it.

A readability score will tell you approximately how complex your writing is. At the library, we aim to write for an 8th grade reading level. Although we are a University, we don’t want our users to find the most challenging part of their research is understanding our instructions. A good resources for readability scores is http://readabilityscore.com/. I also get a report on every page in the CMS and LibGuides with a Readability score, so if you have questions, you can always drop me a line.

Watch out for the section on European and Canadian accessibility laws.

It’s nice to know that there are many other laws in the world to help make sure websites are accessible. However, none of them apply to you are content creators. They will ask you questions about laws with names like EU 307 567, and it is very easy to get tripped up. (I got some of these wrong, and I know all about these laws.) It’s ridiculous, but now you know to take notes in that section. I have been assured that the new GVSU-centric training will not include quizzes about European accessibility laws.