In a word: no. As stated by the WAI, new links can be “…disorienting for people, especially people who have difficulty perceiving visual content”.
As with anything else on the web, there’s always an exception, and you should definitely check out the link above to read about some specific scenarios where opening a new tab/window can be appropriate. But those scenarios are rare. People know how to use the back button. Depend on that, rather than a new tab/window.
Today’s post is a quick one, to share this awesome captioning style guide from Humber College, which I found while trying to figure out the appropriate way to caption a choir singing a round acapella (I still don’t know the answer). In addition to the most helpful information I found on captioning music, also included are suggestions on timing, dialog, sound effects, and accents. Since we need to caption almost every video on our website, it’s worth a quick glace to get an idea of how it should be done.
Recently I found a post which explores some of the limitations of automated website accessibility checking tools by building a site that scores a 100% on Google’s accessibility checker, while being completely inaccessible.
That post explores the very real limitations of automated tools. Tools like that can be useful, and help us by checking some of the low hanging fruit. But they never do a great job. For instance, just to highlight one obvious example mentioned in the post, here’s some examples of alt text on a logo which links to the homepage which would pass an automated check, but are really terribly inaccessible:
You know what some good alt text would be? “Visit the LCC homepage” – it’s a linked logo, so provide the purpose of the link.
When it comes to automated accessibility tools, use them to give you an idea of the overall accessibility of a page, but always double-check some items yourself – particularly ones that are difficult to for a computer to check, like link purpose.
Looking for more on alt text? Check out a decision tree for alt text
I know, I know, we’re in week 4, and I’m finally putting out my first post of the year. But it’s 2020. It’s that kind of year.
Last week the web team attended the 2020 HighEdWeb annual conference. This is one of my favorite conferences, and it was even better this year because it was absolutely free online (though in central time, which made for some early mornings). Here’s some gems:
It’s an accessibility issue. It’s an equity issue. People skim online. If we make that hard for them, they leave. Take a look at our previous plain language post.
One of the groups at Miami University did a lot of extensive testing. People don’t self serve. If you have a lot of links and resources that you want to put out there, consider a drip campaign to slowly provide those links at a pace people can digest. Use social to highlight different resources at different times. Include titles that highlight the problem the resource solves (“Looking for a tutor late on a Sunday night before class? Look no further!”). Track what you do to see what works (and reach out if you’d like help setting that up!). Rather than a resource page, consider a blog, where those resource links can be provided in context, and do some content marketing for you. We’ve also covered resource pages in the past.
Especially now, when we’re not going to see them in person. Flyers and posters are designed for print, and don’t translate well to digital. If you’re considering putting a flyer or poster online or on a digital sign, reach out – we’ll connect you with some graphic design resources, and help design for the medium you’ll be promoting on.
Carlton did a great session where they detailed extensive user testing before their homepage redesign. They found things like:
While we may think splitting our content up into questions is easier for the student, it actually makes things harder to understand. Read your entire FAQ page, make groups out of the content and write a header for each one, and then rewrite the content in each group to paragraph form. It’ll work better for everyone. Here’s a page with the slides, a sample FAQ with real life before and after examples, and some other resources for why we should stop using FAQ pages. You can also review our previous post on FAQs.
WebAIM’s analysis of the accessibility of the top million homepages came out the other day, and we made the top 25% for the first time. That puts us as #7 in the state for Community Colleges, #13 for Oregon public colleges. Well done SOU for being the highest ranked college in the state!
That’s two successive improvements to our rank. Hopefully we’ll move up quite a bit post redesign! See our entry on WebAIM’s site.
In the last post, I learned that not only does phone number format matter from an SEO perspective, but phone numbers can be really annoying to the blind. Depending on the screen reader, a phone number like 541-463-3000 could be read as “five hundred forty-one dash four hundred sixty-three dash three thousand”. That seems terribly annoying.
I started out trying to implement the solution at the end of this blog post, but then my curiosity got the best of me, and I got digging deep into CSS speech modules. It looks like support is limited even though they’re so cool! But the limited support means I’m going to stay away.
Instead, we’re back to the regular expressions replacements, using the Drupal custom filter module. Currently, we look for
/\((\d{3})\) (\d{3}-\d{4})/
And then replace it with
<a class="telephone_link" href="tel:+1-${1}-${2}">${0}</a>
Over the last few days, we’ve changed that to grab each number individually:
/\(((\d)(\d)(\d))\) ((\d)(\d)(\d)-(\d)(\d)(\d)(\d))/
and replace it with something much, much longer:
<a class="telephone_link" href="tel:+1-${1}-${5}" aria-label="${2} ${3} ${4}. ${6} ${7} ${8}. ${9} ${10} ${11} ${12}">${1}-${5}</a>
It’s a bit of an ugly regular expression, but not only will this hopefully make a better experience for screen reader users, it’ll also introduce a new phone number format as currently recommended by the AP: 541-463-3000.
The other day, Lori pointed out that the phone number format on one of the mockups from iFactory was different from what we normally use. In accordance with AP style, we use (541) 463-3000. But the new mockups use the format 541-463-3000. And it’s pretty common to see phone numbers formatted with two dots: 541.463.3000. Does the format matter?
Yes. It turns out google is better at recognizing some formats as phone numbers than others. That post tested ten different formats, and found that the one we use and the one iFactory used are the ones best recognized by Google. The double dot notation? To quote the linked blog: “”
Of course, that doesn’t settle which of those two is best. So I checked to see if there are any accessibility considerations with phone numbers. There are, but they don’t relate to visible format. All phone number formats are terrible, and something like (541) 463-3000 would probably be read to a blind person as “five hundred forty-one [pause] four hundred sixty-three three thousand”. There’s a fix for that, using aria-label on a surrounding link, but that just adds something for my todo list, and doesn’t solve the debate here.
And that’s how I found myself at 10pm, doing a survey of college websites, to see how they format phone numbers:
| 541-463-3000 | 25 | Harvard, UO, OSU, Washington, UC Denver, KSU, UMass, FSU, F&M, UCLA, MIT, Cal State Fullerton, Ohio State, Penn State, VT, Louisiana State, Wisconsin State, Yale, Georgetown, Alaska, Berkeley, Skidmore, Colby, Baylor, OHSU |
| 541.463.3000 | 10 | Portland State, Gettysburg, NYU, SNHU, WGU, U Phoenix, UVA, Middlebury, GA Tech, U Maine |
| (541) 463.3000 | 1 | Gonzaga |
| (541) 363-3000 | 13 | Idaho, UVM, Dickinson, Michigan State, Kentucky State, U Penn, UConn, Binghamton, Dartmouth, Cornell, Ithaca, Notre Dame, American |
| Mix | 2 | Rutgers, Princeton |
This is just a quick post to share some news about the ever evolving legal web accessibility landscape. The LA Times has a nice write-up of Robles v Dominos, and how by declining to review the 9th Circuit ruling, we’ve conclusively determined that the Americans with Disabilities Act does apply to websites and apps.
While this doesn’t impact the college directly – we were already subject to website accessibility requirements – it does serve as a great reminder that digital accessibility lawsuits are on the rise, and we need to continually work to ensure what we do is accessible.
And remember, that work doesn’t include just websites, but all things posted online, on any website used in relation to Lane. PDFs have some pretty good checking tools that are worth looking at.
While researching the WCAG 2.1 post series, I found an excellent alt text decision tree that walks you through how to select appropriate alt text for an image on the web.
If image accessibility interests you, you might be interested in the WCAG 2.0 or 2.1 post series.
The very first success criterion we’ll look at is 1.3.4: Orientation (level AA). Remember that WCAG 2.1 extends on the work already done in 2.0, so because there was nothing added to parts 1.0, 1.1, or 1.2 we can skip those. Here’s the full text of the new criterion:
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
This is one that definitely feels like a best practice in user experience. Let’s take a look at an the Garmin Connect app, which both follows this standard really well and really poorly at the same time.
Here’s one of the screens showing my steps for the day on my phone:
When the phone is in portrait mode (the way most of us hold our phones most of the time), everything looks good, although the astute reader will note that app violates success criterion 1.4.1). But here’s what happens when we flip that onto its side:
When we’re in landscape (the way most of us should shoot videos on our phone), everything is sideways. It’s, honestly, terribly annoying, if not a little lazy. If those boxes were to all rotate with the screen, and maybe just be oriented a little differently, the screen would be just as useful, and provide the exact same information.
But the connect app also does a good job taking advantage of the different screen orientations to show different information. Here’s another example from an activity a while back:
But this time, when we switch to landscape, we get a different screen:
The developers over at Garmin clearly felt that those graphs only make sense in landscape, where they can be a larger while maintaining proportion. I’m not sure I fully agree – sometimes activities are so long you need a monitor, not a phone – but they clearly feel that the specific screen orientation is essential to the information being displayed.
If you’re leaving out screen orientation as a part of your media queries when developing for the web, then you’re probably in good shape. And, on the topic of good shape, feel free to send me a step challenge on Garmin Connect. I’ve got a camping trip coming up this fall, and for once I’d like to huff and puff less than the other folks with me.
Looking for the rest of the posts in this series?