>> Hello, everybody. Welcome to our virtual session. I'm Gienna Gaeta, a senior consultant at Clarity.
>> I'm Suzie.
>> And I'm Mike. Clarity is a consulting firm in Chicago. The three of us are part of a team that works primarily in Drupal, but Clarity has other teams working different technologies as well, and we are hiring for several different positions at the company. Be sure to check us out if you're looking for a job. I'll post a link for the site in Zoom, Slack, and the chat.
>> Thank you for the overview of Clarity. Suzie, give us an overview of the client Pace.
>> SUZIE MILLER: It's the premier suburban transit provider. They provide transit options for 284 municipalities in 6 counties throughout northeast Illinois. They service more than 100,000 daily riders, ADA paratransit, and ride sharing services. We want to call special sensation to the ADA paratransit portion.
Pace truly believes that their services should be susceptible, and this principle was important for us in determining the objectives of the website redesign.
>> GIENNA GAETA: Thank you, Suzie. We will talk about the work that we did for our client Pace in user testing, accessibility testing, and the prototype that made those two tests possible. We're going to start with design, and we're just going to jump in. Suzie designed websites in the past, and the first thing you think of it who are you designing for. When we took on Pace, who did you believe we ‑‑ we were designing for?
>> SUZIE MILLER: That's a great question. So we knew that Pace had a variety of users. We had new riders who we identified as people who had never ridden Pace, or tourists to the area. We had our regular riders, people who ride Pace on a daily basis. Our on‑demand riders and riders with disabilities, those are the audiences utilizing the ride sharing and paratransit services. And we had an outlying audience, the engaged community members. Individuals who participate in the committees or the boards at the pace ‑‑ at Pace.
>> GIENNA GAETA: Okay. What tied all these user groups together?
>> SUZIE MILLER: As we all know, individual groups will have different needs for the website. But the thing that tied them all together was the main menu.
So we started this project by reevaluating the information architecture of the website, and we proposed to Pace that they split their IA into two main buckets, being Ride Pace and Inside Pace. If you're able to look at the screen and the slides, you can see the proposed design for the main menu. I'm going to show you another slide, and this is the proposed design for when the main menu is open.
So each of these main bucket have their own menu. Ride Pace has callouts for tools for ridership, and then you can see underneath that you have your secondary and tertiary‑level menu items. And Inside Pace has a same layout. Their tools on the top are different, customer service, doing business, and news and events.
>> GIENNA GAETA: What did the menu look like before, Suzie?
>> SUZIE MILLER: That's a good question. [Chuckles].
This architecture was a drastic switch for Pace. If you're able to look at the screen, you can see the current Pace header. As you can tell, it's pretty fractured. It's not clear to me as a user where I'm supposed to go or click on.
So this proposed IA and main menu were really simple for Pace. They seemed simple for Pace. And they were into the idea, but of course we wanted to make sure that would meet end user expectations.
>> GIENNA GAETA: So you guys decided to do user tests. So why would doing this user test be valuable?
>> SUZIE MILLER: Other than, you know, making sure this proposed structure met user expectations, there was a lot of discussion internally within Pace about the terminology they were using in the main menu.
You know, some people thought the terms were clear. Some people thought they weren't clear. This was another ‑‑ another reason we decided to move forward with user tests.
>> GIENNA GAETA: Got it. So what was your starting point, once you decided to do the user test?
>> SUZIE MILLER: We met with Pace in person, and we went with worksheets prepared beforehand, and then we helped them fill out these worksheets.
On the screen right now, you can see a screenshot of these worksheets, and you will be able to see that we were ‑‑ we identified the audience, the user group that Pace wanted to test, the task scenarios specific to that user group. And then we also had ‑‑ helped Pace determine their qualitative and quantitative metric for the tests.
>> GIENNA GAETA: And after you decided all that, what did the actual test day look like?
>> SUZIE MILLER: On test day we had six participants who utilized InVision prototype. For those that aren't familiar with InVision, it's a software that helps us turn otherwise static JPEGs into interactive prototypes. The users were able to go through task scenarios as if they were on, like, a developed website. Each test was about 20 minutes, and we had six observers watching the test from another room.
>> GIENNA GAETA: So what were the results of the test?
>> SUZIE MILLER: We got great feedback from our users. The first is, you know, did the proposed IA make sense to our end users? And they concluded that it did, that Ride Pace and Inside Pace made sense to them. Our users also generally approved of the terminology that Pace had identified to use in the test. And we got some actionable design feedback well.
>> GIENNA GAETA: What was that actual design feedback?
>> SUZIE MILLER: Yeah, this is the good stuff. [Chuckles].
So the first thing is that when the main menu was open, the parent items were given a bold type treatment.
And our users told us that just the simple bold treatment did not indicate to them that you could click on those items.
So we went ahead and updated the designs. We gave that text an underline, as well as a bold treatment, just to help indicate that it was clickable.
We also good some feedback about how we were handling the home page.
So the prototype that the users were exposed to had a significant portion of the real estate of the home page dedicated to a tool we call the trip planner. The trip planner just allows an end user to pick a departure point and an end point, and kind of ‑‑ you know, establish a time of day for the trip. And then get trip recommendations.
Our users told us that they wanted access to more tools, and so we took that same amount of real estate and divided it into three sections. So our users are now able to quickly access the real‑time status of the bus, round trip information, and the trip planner tool.
>> GIENNA GAETA: Let's ‑‑ cool stuff.
>> SUZIE MILLER: Yeah. So at this point, you know, after wrapping up user ‑‑ user testing, Gienna, your portion of the project took off. Can you talk to us about that?
>> GIENNA GAETA: Yeah. After the user test came to a close, the next thing Pace wanted to focus on was accessibility.
As Suzie said at the beginning of this presentation, Pace ‑‑ Pace has a large ‑‑ has put a large emphasis on their ADA users. Like they provide equal access to the bus services, they also wanted to provide equal access to the website.
The starting pointing was to determine a level of compliance.
We started with the web content accessibility guidelines, otherwise known as the WCAG.
This is a set of guidelines put together by a renowned organization that is really out there, to come up with requirements for making websites accessible.
They currently have three compliance levels. A, AA, and AAA.
A being the least ‑‑ the least amount of accessibility efforts, as in it's legal, you're good to go.
AA taking it to the next step, and making the site even more compliant.
And AAA being the most compliant website you can have.
Unfortunately, Pace ruled out AAA right away, because it would ‑‑ they wouldn't be able to go AAA without compromising their content. When decided whether they wanted to do an AA website, Clarity took each of these AA requirements and assessed each one of those with the development team, the QA team, and design team to see how much effort meeting each of those requirements would be.
In the end, Pace concluded they were going to launch with a level A compliance, with the hopes that with enhancements after launch that they could eventually become a AA compliant site.
>> SUZIE MILLER: After you guys determined the level of compliance, Gienna, how else did you prepare for the accessibility tests?
>> GIENNA GAETA: Yeah. Our next step was to do an alphabetical user test, like how Suzie tested the main menu, Pace wanted to test the accessibility of their site.
We started preparing for the accessibility test by finding people with disabilities. Pace has a large community of people they consult for accessibility purposes. So they were able to get four users with disabilities for the website to test.
They also scheduled a test environment, and they set up all the technology necessary for the test.
Meaning they got the technology that the users were comfortable with, that they use at home, as well as the technology needed for the observers to watch everything that was going on in the other room.
>> SUZIE MILLER: What kind of tasks did you ask your users to complete?
>> GIENNA GAETA: Sure. Just like for your user test for the menu, Suzie, we wanted to give our users the same type of tests. They really revolved around what anyone would go to the website for, which is how do I use a Pace bus to get to where I need to go to? What time would I get there? If I was on a Pace bus. And how much would it cost?
>> SUZIE MILLER: Gienna, can you tell me more about your test participants? What qualified them for the test, and maybe what kind of technologies they used?
>> GIENNA GAETA: Sure.
So if you go to the next screen, you will see a matrix of users that we tested. There were a total of four users. Two of them who were legally blind, and two of them who had intellectual disabilities.
For the users who were blind, we had them test on both desktop and their mobile devices.
On desktop, they used a software called JAWS, which is a popular screen reader, which reads everything on the screen to the user, so that they can experience a website without needing to see it.
And similarly, the iPhone and Samsung have reprogrammed screen readers on their phones so that they could accomplish the same goal on their phones.
The users with intellectual disabilities just used a regular desktop and mouse. You'll see at the bottom we rated the users with an ease of use score . As you can see, with Jim, he was rated a 4. And we really gave these scores based on the time it took to complete each assignment.
We discovered that Jim was a 4 because he has been blind his whole life. So he has used the assist active technology JAWS and his screen reader for a very long time, so he was very comfortable completing the tasks. He was just a pro going through each one, finding what he needed, and moving on.
Whereas someone like Maurice who had recently become blind, it took them a little bit longer to complete each task just because they weren't as familiar with their own technology.
>> SUZIE MILLER: What else did you learn from the test?
>> GIENNA GAETA: So we learned that the prototype we created was accessible.
In the end, we concluded that all of the users were able to complete each 12 assignments. That was a great success for us and Pace. Everyone works ‑‑ uses technology differently, and Pace really decided that they're going to stick with their design. They're going to stick with what we're going with for their new site.
So in order to test a successful prototype, someone had to build the successful prototype.
So right now I'm going to hand it over to Mike to talk about how he made that possible.
>> MIKE ROMAN: All right. Well, there were three main things going through my head as I was implementing the accessibility demo site. And the first one was to make the code portable so I wouldn't have to repeat a lot of work.
Since we decided that the live site was going to be in Drupal 8, it was an easy choice for me to build the demo site in Drupal 8.
And second was to respect the scope, time line, and budget for this phase of the project by keeping my focus on accessibility, and meeting the success criterion we agreed with the client that we were going to cover. Other things such as loading all of their content or having all of the themeing completely polished was out of scope for this phase, and saved for the next phase of the project, which is building a launch‑ready website.
And third was to go through Suzie's designs and tackle the more complicated things first. And there were two things about their design that stood out to me.
First, it was this component you can see on the left that I called tabbed tables. I used a contributed module to implement this, but the screen reader we tested with was skipping over the table data. And we decided the best course of action with respect to both accessibility and project time line was to simplify the design of this component and not use tabs.
And second on the right, I knew the main menu would also be complicated. Even before taking accessibility into account.
So this image on the right here is this part of the menu that I saw earlier. I used a contributed module to implement this as well, but ‑‑ because it is a part of the menu, but also different and more complicated than the other normal menu items.
And just showing also to cover the accessibility part of the main menu. So I needed to use custom JavaScript to implement the area tags, so those using screen readers could know if the flyout was open or closed. I needed to create a closed button for the layout ‑‑ for the flyout and make sure it was accessible via the keyboard. And I needed to ensure the HTML was correct for navigation of the menu structure.
And after finishing the accessibility demo, we were ready for phase 2 of the project. Building the site that Pace would go live with.
I could have continued adding to the demo site until it was launch‑ready, but instead I decided to keep the demo site intact and start with the completely fresh Drupal install, and then port over the code from the demo.
This helped me review my own code during this transition process and make any necessary adjustments before starting the phase 2 work, like creating content types and views and all the other Drupal stuff.
And we're still working on that. We're not done yet.
But I'll say that things are going well so far, and we're expected to go live next month. That's all we have. Thank you so much for joining us. If you have any questions, we'll just cover a couple of logistical things before we ‑‑ before take‑home, but you're welcome to ask questions.
So we have contribution day this Saturday is obviously going to be virtual. That's Saturday, 10 a.m. to 4 p.m.
And I love to get ...
Get Andrew to pitch his Contribution Day plans.
>> ANDREW OLSON: Sure, yeah. I'll say something briefly. On contribution day I spoke about a live captioning tool, and we're going to be using that time on Saturday to define a few more things about our free tool that helps any event become accessible by using captioning.
I also will take this time to thank Clarity, all three of you, for the organization you work for, to sponsor the actual captions for the sessions today. It's much appreciated. We have a live captioner and closed captioning available for all the sessions, and transcripts will be up on the MidCamp site.
With that, we should take some questions, and I can read them off.
One of them ‑‑ thanks for answering, 0 was not useful and 5 was very useful on the scores. That was helpful.
But another question is, what was your solution to tabbed table replacement? Mike.
>> MIKE ROMAN: Sure. So I'll start by saying that the one ‑‑ the module we tried was called ... A11Y Paragraph tabs, because we used Drupal Paragraphs for most of our content.
My ‑‑ my gut feeling, when looking at the design, was that it was ‑‑ it might be too complicated for a screen reader to handle.
I wasn't sure.
And we ‑‑ we really just made the ...
I think we just made the tables just stacked vertically, instead of using tabs at all.
>> ANDREW OLSON: I had a question. You said you used a contribution for the main menu. What was that for the flyout menu? Did you say what module that was?
>> MIKE ROMAN: No, I didn't, but I anticipated that question.
Used menu items extras, and that ‑‑ that just allows you to add different fields. And in our case, we just use a paragraph field for that.
So we have a ‑‑ like, a field for the icon image, and, you know, a link, just like a normal menu item link.
And those, to make the ‑‑ like, the three ‑‑ those three items going across the flyout, those were just three of those paragraph types connected to the ‑‑ that first level of the menu.
So in our case, the Ride Pace and Inside Pace.
>> ANDREW OLSON: Interesting. Okay. Yeah, I've used the menu item extras, so that's really cool. Thanks.
>> MIKE ROMAN: You can ask questions to Suzie or Gienna too. You don't have to just ‑‑
>> SUZIE MILLER: You're handling them so well, Mike!
[Laughter.]
>> ANDREW OLSON: I'll ask. Were you ‑‑ I'll keep going. Were you able to participate, each one of you, in observing the people using, for the user tests? Or was that information that you received after the fact?
>> GIENNA GAETA: For the menu user tests, Suzie was the moderator, and I was one of the observers. For the accessibility test I was the moderator, and we had some other people on our team observe.
So it was cool for me, because I got to be both a moderator and an observer. So I had watched Suzie moderate her user test, since she went first. So when I went to moderate my accessibility test, I kind of got to see how it was all going to happen.
>> ANDREW OLSON: What was the biggest impact of observing? That must have been really, really interesting.
>> GIENNA GAETA: It was really interesting. It was cool to time the users, and for a few things, we watched them struggle, and, like, one specific point in the user test. And that was actually ‑‑ they couldn't click on the ‑‑ they would go to click on the ‑‑ the item in the ‑‑ the menu that wasn't highlighted that Suzie ended up putting underlines under, and we just watched them ‑‑ in the other room, you're like, "Oh, you're hovering over it! Just click it!"
But other than that it went smoothly. Suzie had a cool setup where we took notes of what they were doing on Post‑it notes. At the end of the day, all our notes on what all the users did were up on the board. Actually, I think there's a picture of it. In the results section.
>> SUZIE MILLER: Yeah, there is.
>> GIENNA GAETA: Yeah. So you can kind of see that EF, those are each one of the users.
And we had little notes on each one pinned on the board.
>> ANDREW OLSON: That's great. There's a question on the channel. Roger, you can unmute yourself. You are unmuted, if you want to go ahead and ask your question.
>> ROGER: Hi there. Not sure if this is working.
>> ANDREW OLSON: We can hear you. Yep. While we're waiting, Mark also had a question, and I unmuted Mark. Until Roger gets it figured out, Mark, if you want to talk, you should be able to.
>> [Indistinct].
>> ANDREW OLSON: I'll read them off. For Roger: Do you know if there's any sort of online virtual accessibility focus testing available? Like usertesting.com?
>> GIENNA GAETA: I don't know ‑‑ we only really used ‑‑ consulted the WCAG guidelines, but maybe someone else would know.
>> Is this like getting users for testing?
>> ANDREW OLSON: Looking at the link, yeah. I think it means focus group testing. Yep, that's what Roger is saying.
So being able to find people to help test. Pace had a built‑in community who can help them test to know if there's any other ability. Yeah, not every organization as access to a community like Pace does. That's very unique. I don't know ‑‑
>> SUZIE MILLER: So we have leveraged a relationship with City Tech Collaborative in the past. They used to be an organization called the Cut Group, who was kind of absorbed by City Tech Collaborative.
And we utilized them as a resource to find test participants in the past.
>> ANDREW OLSON: Mark was asking, for users of assistive devices, is there any room for using progressive enhancement to keep it simple for assistive users, and doing something fancier for other users?
>> MIKE ROMAN: That's a good question. I think that ‑‑ at least with WCAG guidelines, there needs to be an accessible alternative for things.
But as far as taking that approach, I think ‑‑ I think that is possible. But we just didn't explore that for this project.
>> ANDREW OLSON: I can speak able to. The project I'm on now there's a need for an ambient video in the background. And that's what I would call something fancier for users. And that's okay to use, as long as people that need to turn it off and keep it turned off have that ability, then that's what we implement. We try not to add something like motion or video with sound that users can't control or take back over the screen from them. That's what I've done with it.
We can have fancy things, but we need the ability to let people ‑‑ and remember that they chose not to have those fancy things. I don't know if that answers that.
Another thing, Thomas Hefner, the Drupal accessibility channel, I learn something from that at least weekly. Joining the Drupal Slack for accessibility channel is outstanding.
>> MIKE ROMAN: Before I forget, Suzie, could you go to the last slide for the feedback link?
>> SUZIE MILLER: Absolutely.
>> MIKE ROMAN: All ‑‑ all sessions have a place for you to do ‑‑ give the speakers presentation feedback. If you copy that link, follow that, and fill it out, we would appreciate that.
>> ANDREW OLSON: Great. I think we'll give it nor minute. If there's any last‑minute things you wanted to say. Definitely fill out the feedback form. Otherwise, this was a excellent session, and hang out for more sessions. I'm going to stop the recording, and thanks, everybody, for your time today.
>> SUZIE MILLER: Thank you.
>> GIENNA GAETA: Thank you! Is.