All right. Now for our neighbors in Cambridge, Harvard University, we have three speakers. The focus is Breaking, University news site redesign puts accessibility above the fold. Speaking today, we have Aaron Baker, who is the senior associate director of content strategy for Harvard Public Affairs and Communications. He stitches together systems and services to support content operations and data analytics for the Harvard University homepage, the Harvard Gazette, as well as Harvard's flagship social media accounts.
Second, we have Janell Sims, who is manager of digital accessibility services at Harvard, where she works to build a culture of inclusion and support for the university's accessibility commitments. Prior, Janell worked in web and content strategy at Harvard Kennedy School and Harvard Law School.
And then we have Molly Miles, who is a content manager and analyst for Harvard Public Affairs and Communications. She works with vendors on the Harvard Gazette site to complete maintenance and ongoing improvements. She also supports the departments' and content strategy teams' analytics reporting needs.
So with that being said, thank you all three for presenting today. We really appreciate it. And I'm going to hand it over to you.
All right. Thanks, Ron. Getting set up.
Yeah. And we can see your screen, Janell.
All right, we'll go ahead and get started.
Great.
[MUSIC PLAYING]
Good morning. Reporting live from our studios in Cambridge, I'm Aaron Baker.
And I'm Janell Sims.
And from the satellite studio in Rochester, New York, I'm Molly Miles.
Coming up, our coverage of this monumental project will begin with how it all started, how accessibility works, what the policy is like at Harvard, how we found competent expert partners for our project, what our process was like, and finally, we'll show some features that we built with accessibility in mind.
Wow. Thanks, Aaron. Sounds exciting. Can you give us some information on the background about this project, how it started, and where it is now?
Well, Janell, you and I have both been covering accessibility news at Harvard for quite a few years now. Starting back in 2019, we both worked on a project to redesign the Harvard University homepage. In that endeavor, we leaned into accessibility, not just to fulfill some legal requirements, but also to showcase best practices for the Harvard community and for higher education more broadly.
From our initial RFP, the Q&A we had with prospective experts, and through final interviews, we used accessibility back then as one of many criteria in order to identify and vet potential partners to develop our site. All that to say is, fast-forward to today, it wasn't our first rodeo.
Today, we see the Harvard Gazette, the official news website for Harvard University. And just like other news university websites, it covers campus life and times, university issues and policies, storytelling around innovations in science, teaching, and learning, and broader national and global analysis. The Gazette also helps to distribute stories from university affiliates. Our audience comprises Harvard alumni, staff, faculty, students, and the broader community, including some who have no formal affiliation with Harvard at all.
The Gazette is produced by HPAC. That's Harvard University Public Affairs and Communications, the university's central communications office. There's three teams within HPAC that contribute to the success of this publication. We have the Gazette editorial team, the creative multimedia team, which has designers, photographers, videographers. And then there's the content strategy team, which also produces and maintains the Harvard homepage and our flagship social media accounts.
Amazing. Thanks for that background information. And for our viewers watching here and at home, you've probably heard the term "digital accessibility." But today, we're going to go in depth to find out exactly what it is and why it's so important.
So digital accessibility means that we're making digital content that is usable by everyone at the same time and with the same ease of use, including and especially people with disabilities. So more than just access-- access can sometimes be used interchangeably with accessibility. And while obviously, it's important for everybody to be able to access your content, accessibility takes it a step further and says that everyone should be able to interact and engage with your content in a meaningful way. Really, what we're doing is creating an equitable experience for all of our users.
So why is accessibility so important? Well, just by sheer numbers alone, about one in five people, or about 20% of us, have at least one disability that we've actively disclosed. So just by the numbers, if you're excluding people with disabilities, that's about 20% of your web traffic that you're shutting out.
Accessibility also promotes a sense of inclusion and belonging. You truly can't be inclusive without also being accessible.
And then accessibility makes really good business sense. It also reduces your legal risk, not only from the financial implications that come with that, but also thinking about our reputation. We want to have that posture of welcoming and inclusion.
And then finally, improving the digital experiences for everyone-- accessibility doesn't mean you're just designing for a small subset of people or, even worse, that you're creating a parallel design for someone else. Instead, we're baking accessibility into the core of our design so that we're creating an improved and enhanced experience for everybody.
So how are people affected? Well, we think of disabilities in four major buckets. So the first is visual, people who might be blind or color blind or have low vision.
There's also motor disabilities. So these are things like paralysis, tremors, carpal tunnel syndrome, repetitive strain injury, things like that. Auditory disabilities could include people who are deaf or hard of hearing.
And then finally, cognitive disabilities, so things like memory, difficulty interpreting information. And this is a very fast-growing group of disabilities, not because more and more people have them, although arguably, that's true. But people are also feeling more empowered and comfortable speaking up and identifying as having these disabilities.
There's also lots of assistive technology available that people with disabilities are able to use. So people with visual disabilities might use a screen reader, which is software that reads aloud all of the text on a screen. Screen magnifiers are also used by people with low vision, and high-contrast mode as well, changing the colors to customize to fit many different vision spectrums.
And then motor disabilities, so people using things like wands, eye tracking, different kinds of mice, mouse, pedals, things of alternative devices. For auditory, there's captions, transcripts and sign language. And then finally, cognitive, things like selecting the font that's easiest to read or highlighting text as you read it, and then dictation or speech to text.
So how is accessibility measured? Well, there's an internationally recognized set of standards called the Web Content Accessibility Guidelines, or WCAG. It's pronounced "wih-kag," and it's divided into four principles-- perceivable, operable, understandable, and robust. And there are three cumulative levels of compliance, A, AA, and AAA. So level A criteria are the most important base-level issues, the most critical that you definitely want to address first. But the good news is, usually, they're pretty easy to fix.
So AA criteria might take a little bit more thought and planning to implement, but are still going to have a big impact on your users. And then AAA issues, you might want to sprinkle in here and there, depending on your use case and user groups.
There are two current versions of the WCAG. 2.1 was released in June of 2018, and 2.2 was released just in October of 2023. But 2.1 is still the version that's most in use.
Wow, Janell. I think I can already see where this is going. What happened at Harvard, then? And why did they need a digital policy at all on accessibility?
Well, Aaron, digital accessibility has had an important journey at Harvard. So let's take a look at the policy that has helped prioritize accessibility all across the university.
So as a little background, in 2015, the National Association of the Deaf, or NAD, filed a lawsuit against Harvard. The DOJ, the Department of Justice, contended that universities were discriminating against deaf people by, quote, "failing to provide equal access in the form of captions."
So the lawsuit was settled in 2019, and it spurred the university to take action. So we implemented a digital accessibility policy in 2019. And then in June 2023, we expanded the policy. So we're going to take a closer look at each one of these policies and what they mean.
The digital accessibility policy that went into effect in 2019 focused on public-facing websites. It set WCAG 2.1 AA as the standard for content. Along with the policy, a new Digital Accessibility Services team, or DAS, which I'm a part of, was established. The policy also created a network of Digital Accessibility Liaisons-- we call them DALs-- that are instrumental in coordinating accessibility efforts at schools and units all across the university.
As I mentioned, the 2019 policy was in direct response to the lawsuit and settlement. But in 2023, the policy was expanded. This time, it was the university looking forward, being proactive instead of reactive. The expansion includes all digital content and technology, so whether it's public facing or internal. And this is key to the Harvard Gazette, which has a very large internal but also external audience. We wanted to make sure that everyone's experience was accessible.
Wow. Thank you for that insightful overview, Janell. I can see how these policies had a big impact on web projects like the Gazette.
Absolutely. And, Aaron, I'm actually wondering if you can tell me, how did you find a vendor that you could feel confident was going to share Harvard's commitment to accessibility?
Wow, that's a great question, Janell. I'm glad you asked. Whether you have an internal team and are looking to build your web project, or you're trying to court expert partners to help you through a big project, your first step is to set your project's goals. For us, we don't have an internal web development team. So we're going to use these goals to help us figure out how to build our team and find those partners.
So the main purpose of the Gazette redesign project was to update the design and the capabilities of our WordPress news website in order to do more rich and in-depth storytelling about Harvard. The timing of the project was really predetermined by multi-year financial planning. But we take advantage of this moment to do fresh discovery, stakeholder interviews, user surveys, and other periodic research activities in order to inform our decisions from now and going forward. For our team at HPAC, we knew that the project would result in a new WordPress theme, new code, and therefore, we knew from the get-go that we needed to address accessibility first and foremost, most especially because we don't have an internal team to fix things later on. So we must do all of this work by using consultants and third-party vendor partners.
So unlike previous projects like the Harvard homepage, where we just mentioned the importance of accessibility, this time, we decided to make it the first and main point in our RFP. So when you're in this situation, when you're looking for help building your website, generally, you want to use your project goals to then write an RFP. And we found that taking great care in writing the RFP and mentioning things like accessibility first, it helps us attract the right pool of vendor-partner candidates to submit proposals to us. We found that agencies that have a handle on accessibility, meaning they can talk and demonstrate a nuanced approach to compliance, those agencies typically have their stuff together in a lot of other ways. So in other words, we're using accessibility competence as an indicator of a mature consultant or vendor partner.
It goes without saying that Harvard is a complicated place. And we don't fault anyone for having the wrong idea about us or what we're building. But rather than have a bunch of agencies get the wrong idea and submit suboptimal proposals to us on how to help us, we like to include this window of opportunity before they submit their proposals that we call a Q&A session.
And this is really where we can clarify to them some important points that they might have about the project, or our working style, or our organizational structure, all kinds of things. So, for example, many vendors will ask how many people they're going to meet with in order to provide an accurate estimate for their proposal. And I think that's a really great question. You could meet with 2 people. You could meet with 200 people at Harvard.
Other vendors may ask something so elementary that you question whether they know what they're doing at all. And so we found that listing everyone's questions and then listing everyone's answers-- or our answers to everyone's questions publicly, it saves everyone time. You learn a lot about an agency by what kinds of questions they ask. And likewise, your public answers help other agencies learn about you.
So at the end of this whole process, the Q&A window, everyone submits their proposals, and our team picked the best one or the best few to interview until we found just the right match. And for the Gazette project, we chose a joint proposal by agencies Furthermore and Human Made.
So now that you know a little bit about what we're looking to build, let's talk about how accessibility was incorporated throughout the work process, right, Janell?
Yes, that's right. There is not a switch you can flip and make all your digital content accessible. As much as we would like to have an AI tool or a bot or something that can make everything accessible all at once, the reality is, it's a process, step by step, issue by issue, that ensures accessibility progress. The most important thing is to remember to implement accessibility as early as possible in the process.
And so in the Gazette project, we aimed to do just that-- incorporate accessibility in the very early designs in Figma. So the designers at Furthermore already had a head start. Their designs were beautiful, but also were meeting most accessibility guidelines. And so our DAS team was able to review the designs and spotted a few small but important accessibility issues.
In this example of a form design, there is placeholder text being used as the field label. So this can be an issue for people with low vision because it's hard to read, and also cognitive disabilities, because once you start typing in the field, the placeholder text disappears.
So we made a note in Figma that the placeholder text should be removed and instead replaced with a persistent visible label outside of the field. So the design was fixed before anything was baked in the code, which saved us so much time and money down the road. The fix in Figma was super quick, super easy, much quicker and easier than it would have been to fix after it was already built on the site.
And then once the designs were coded and implemented into a development environment, the engineers at Human Made, along with our DAS team, tested the site against those WCAG standards to be sure that the Gazette site complied with Harvard's policy.
But we wanted to take it a step further. And so we used Fable, which is a company that enables you to test your product with actual users of assistive technology. We wanted to be sure that our site not only met accessibility guidelines, but that we could really enhance the experience for people with disabilities.
So when we did our own testing, we thought we did pretty well, maybe five stars. But after testing with Fable, we were reminded that there's always improvements to make, and we'll always be chasing that last star.
So, Aaron, I'm going to share an exclusive interview with Roger, one of our favorite Fable testers. Roger is a blind accessibility tester from Maine, so you might pick up on his accent. Roger uses a screen reader to navigate the web, and so we asked him to read through the front page of the Gazette site and just see what his reaction was as he navigated through the main menu with a screen reader. So I'll play the interview with Roger.
Navigation region, list of six items. Link Health. Link Arts and Culture. Link Science and Tech. Link Work and Economy. Link Nation and World. Link Campus and Community.
So all of the NAV bar links are working fine.
Sections navigation. List of toggle menu button collapsed.
And we have a toggle menu collapsed. Toggle menu button, collapsed. List end. Toggle menu button collapsed.
And so I am always one who likes to know what trouble I'm going to get into before I get into it. So, for me, I would say that the toggle menu--
Toggle menu button collapsed.
What sort of menu is it? Is it a options menu? Is it a preferences menu? Is it a page orientation menu? Is it a navigation menu? I'd like to have a little more clarity on--
Toggle menu button collapsed.
Toggle menu button-- well, what sort of menu is it? Is it a restaurant menu? Is it a vendor menu? Is it a course outline menu? So I'd like to have a little clarification, myself, if I was reading this, before I would choose to expand the menu.
Thanks, Roger. So when we tested the design with a screen reader, we actually found that button was announced correctly. So it was announced as a toggle, it was announced as collapsed, and labeled as a menu. So check, check, check. It passed the WCAG guidelines.
But Roger's feedback made us do a double take. That button wasn't as accessible as we thought. So we made a very simple change, literally just changed the label to Main Menu to differentiate it from the navigation menu. It was such a simple change, but what a big impact on our users.
So, Aaron, what kind of accessibility features are built into the Gazette site?
Well, Janell, I am just getting word that our field correspondent, Molly Miles, is here, who has an update on these new features. Molly?
Thanks, Aaron. So the new Gazette website, of course, you want to build the newest and coolest features in. But doing that accessibly is a different story altogether. So not only was creating an accessible site a priority, but we also really wanted to create an enhanced experience for our site editors and give them a lot of design options.
So before we could even get to one of the coolest features that we made, which was a palette picker, we had to iron out what colors and color combinations met our contrast requirements. We used a free tool called Contrast Grid that lets you see what works at which compliance levels, whether it's A, AA, AAA, or did not pass.
So we put in all the color-- the hex codes, which is how you denote in HTML what your color is-- into it, and we were able to get a list of all the colors that are compatible and which level they meet. You can see from all the white space all of the ones that were immediately knocked out. And you might think, well, that's not a lot of options left over. But actually, it's quite a bit.
And not only did we get this very helpful visual guide, but this was also something that we could share with our site editors, as well as some of our graphic designers, as a cheat sheet for them to reference when making graphics.
So as an example of what this palette picker looks like in motion, we have a bunch of different header styles for the Gazette. And in order to make it feel like we're giving our editors robust options that also work for all range of users, we used this color palette picker, which looks like it has just six colors. But each of those has its own variation using dark backgrounds with light text or light backgrounds with dark text. So even with just a small preview you can see with just three colors, there's a ton of options in there.
And another example of this in progress-- so this is a feature we used on a lot of blocks throughout our site. So this is the Harvard quote block. And you'll see in the background the color palette changing. And then as I was talking about, the darker backgrounds with lighter text or lighter backgrounds with darker text. And these all meet our contrast ratio requirements.
And another feature we used, while not necessarily considered a feature in the general sense, was actually adding guardrails. Not only do we have our core team of site editors, but we also have a lot of contributors to the site, to a section called News+. So it's a way that we incorporate news from all over the university into the website.
And these users, they run the gamut of experience and level of expertise. So we really had to have a simplified experience for them while still maintaining our accessibility guidelines. So to make it easier on them and on us, we implemented this scaled-down experience for adding new content, while also meeting our guidelines.
So, for one, as a template, it's a fixed template with just a header image, headline, and a section for copy. It supports one image, which makes it a lot easier for us to monitor, make sure they're uploading things at the right size. And then content-- content has a character limit, but users can still add links.
And with that, I'll pass it back to Janell in the studio.
Thanks, Molly. And there's one other accessible feature I wanted to share with you all this morning. Similar to the quote block that Molly just showed, we also have an audio quote block, which pairs an audio file with an attribution. So when we tested the audio block, which shows an audio file and the citation or the person who said the quote, the design looked great. But when we tested it with a screen reader, we found something wasn't quite right.
So I'm going to play a snippet of what it sounds like with a screen reader reading through the block. So it may sound a little odd if you're not familiar with screen readers. And the volume is a little low on this video because we were just using it for testing. But see if you can tell-- as the screen reader goes through the page, see if you can tell what's different between what it looks like on the screen and what's being read as the screen reader cursor moves through the different elements.
The neural circuit. And now we know that neurons-- audio controls, group, play button. Elapsed, zero-- duration, air play, more, end of audio controls. Group, Paolo Arlotta. You are currently on a text element.
Did you catch that? Notice anything off? I'm going to play it again and just see. So there's the quote block, the name of the person who said it, and then the audio control, the audio player. So see if you can tell as the screen reader goes through which order it's going in and if it matches the visual order. I'll just play it one more time.
The neural circuit And now we know that neurons-- audio controls, group, play button. Elapsed, zero-- duration, air play, more, end of audio controls. Group, Paola Arlotta. You are currently on a text element.
Did you catch it that time? All right, well, what we found was that it wasn't being read in the logical order that was displayed on the screen. So instead of reading the person's name-- instead of the person's name being read right after the quote, it was pushed all the way down and read after the audio controls, which felt super disorienting. So we fixed the block, and now the screen reader follows the same pattern as the visual design, so the quote block, the name, and then the sound player.
So testing each block as it was being built allowed us to catch a lot of these little things that we were able to fix before the launch. This iterative testing made the whole process more manageable in general.
The neural circuit. And now we know that--
Wow, what a fascinating discovery, Janell. Molly, did you have a story about--
Oh, yeah. We also had our first positive feedback after we launched the site from a 92-year-old team member's mother. She has early stage macular degeneration and rarely offers words of praise, so we've been told. But with our renewed focus on providing a best-in-class experience for all people, turns out all we needed to do to win high praise was increase the default text sizes. Who knew?
Well, happy birthday, Terry's mother, 92. Thanks, Molly. What a heartwarming story.
And last but not least, for sure, is we have ongoing maintenance. So how can you be sure to keep accessibility front of mind after launch? The key is iteration to maintain and even elevate your digital products.
So for the Gazette, we continue to share updated tools, articles, and available trainings to our editors to help them keep accessibility in the forefront of their minds. We don't want to stop improving just because the project is over. Onscreen is our accessibility cue that we currently have in Jira, which we use to track our tickets and development for the site.
So, for example, we discovered an issue with the mega menu not closing when a screen reader moves out of it-- not a critical issue for launch, and it actually is going to involve a pretty complicated fix. But it's something we're definitely working on, because we know it's important to our users. And when there are new designs or components for blocks, we partner with our friends at DAS again to check for any accessibility issues.
And to wrap this all up, here are some key takeaways from today.
You need to value empathy over expertise. Also, accessibility is non-negotiable.
It's so important to make accessibility a priority in every phase, especially early on. And collaboration with internal partners is key.
And don't forget, it's so important to test with the right audiences. And remember, accessibility is functional, inclusive, and beautiful.
Thanks, everyone. Molly, thank you so much. Thanks for watching.
That was fantastic. I love the format. Really, fun and entertaining and informative all at the same time.
I had a question. Now, how has the Harvard policy bolstered your ability to move forward with digital accessibility? DOJ rules and accessibility laws are improving, but how does the policy give Harvard accessibility leads more strength in compliance across the university?
That's an excellent question. I will say before the policy, Aaron and Molly and many others across campus and myself were definitely working in accessibility and encouraging people to make things accessible. But it was really difficult to get buy-in because we didn't have that official formal policy. And so after the lawsuit went through and the settlement, we like to say it was a silver lining of something that's not great to get a lawsuit, but a good outcome was that we did get that policy, and it made such a difference to be able to have that top-level policy that we can now point to that really gives that authority to make something accessible. So it just made getting buy-in much, much easier.
So the whole-- we've shifted now. Instead of trying to get everybody to get buy-in, now it's like, well, now how do I do it? I don't have resources. Tell me how to make things accessible, which was a step in the right direction maturity-wise. So the policy was hugely important to make sure that all of our-- that accessibility is prioritized across campus.
And I will say, with the new regulations coming, we're so glad we have this policy because the same regulations apply. The WCAG 2.1 AA standards will be the same as in the new regulations. The scope will just be different.
So it's great that we can tell people, don't worry. If you're already meeting the policy, you're on the right track. So it's not like we're starting from scratch. We already have a good base to go on.
Terrific.
I want to add just one thing that there's not really a lot of enforcement built into the policy. But one of the ways that us at HPAC and the central team, especially on social media, we won't share some other group's video if it doesn't have captions because it's just clearly in the policy. We're doing everything we can to make sure every video we make is captioned. So when someone comes to us and says, Hey, can you just share this? Can you promote it on social, give it a like or whatever, we say nuh-uh. It doesn't meet the university's accessibility guidelines. And it's a great way to just be like, hey, DAS is really helping us out create accessible experiences. So we're just trying to help them out, too, and getting the word out about getting the policy to a point where it's actually making a difference.
Give you a little more power to say no when it doesn't meet the policy, so that's terrific.
A couple other questions-- Our understanding is that Fable requires a pretty costly subscription. How has Harvard contracted with them?
Yeah, that's a great question, too. Fable is amazing, but there is a cost involved. So we started using Fable. Someone on our team actually did a project where they got a grant for a year to do just a trial of Fable. And so we used it in a very limited capacity. So we had a limited number of tests that we could do each month.
And that gave us an idea of what the appetite was, how often it would get used. And so at that lower cost rate with the grant, we were able to do that. And then it was so popular, and we, every month, would run out of our allotted tests. So that's why we realized it was important enough. So in our budget, we actually had to-- we cut some other things to make room for this because Fable was that important.
So going forward, we still have a smaller-- there's still a limited number of tests we can do each month. So we have to use them very strategically. But then we allow groups. If they want to pay themselves, they're allowed to do that as well. So then we're not so limited on the number of tests we do each month.
Question from Lisa Berelson from our Boston campus-- What level of compliancy were you working toward, AA or AAA?
AA. So AA is pretty much the industry standard, for the most part. So our standards are WCAG 2.1 AA. And like I said in the presentation, we would never stop someone from meeting AAA. But we found that AAA guidelines aren't necessarily useful across an entire website. But they can be helpful to sprinkle in as needed for various user groups.
Anyone have any other questions? Again, love your presentation. Really appreciate you speaking with us today. Thank you so much.
Thanks for having us.
Thanks so much for inviting us.