But how to get started? Alex and I had a call where I explained in more detail how I found partners to test with, how I prepare sessions, how to run them and how to follow-up.Thanks so much for sharing your impressions from #CAST2018 and your kind words! It's wonderful to read you and @cyber_decker agreed to pair test!! 😃👍 would love to hear your experience 😉 it's always a pleasure to meet you, I'm already looking forward to the next chance!— Elisabeth Hocke (@lisihocke) August 12, 2018
Even before we had this first call, Alex scheduled a pair testing session with me. Since then I was looking forward to this one and it turned out to be awesome!Had a wonderful call with @cyber_decker, sharing tips and tricks regarding my #TestingTour, what to look out for, how to get it started. And Alex committed to start his own tour before end of this year and share his experience with us! 🎉🚀 How cool is that?!— Elisabeth Hocke (@lisihocke) August 30, 2018
Testing for Accessibility: Why, What, How
As with most partners, we had several topics to pair on in mind. In the end we decided to go for accessibility as we both wanted to get better in this area and for Alex it's becoming really relevant in his current project. Best time to practice together!
In the beginning of our session we decided to first try our skills on a practice application and afterwards tackle a real productive website to apply what we learned. The selected demo we chose was Accessible University 3.0.
"Accessible University (AU) is a fictional university home page designed to demonstrate a variety of common web design problems that result in visitors with disabilities being unable to access content or features. [...] Use the AU site to
- demonstrate common web accessibility principles at trainings, presentations, and workshops on accessible web design.
- learn common web accessibility problems and solutions in an easy-to-understand way." (Accessible University 3.0)
The demo offers an inaccessible site where you can detect at least 18 accessibility issues, a list of all issues including detailed explanations and the accessible version of the site having all issues fixed.
What can I say? We had a blast while discussing our experiences, sharing our accessibility knowledge and finding issue over issue! First, we looked for quick wins using our eyes (we're biased beings), things that instantly stood out that we knew could cause trouble for people who have to rely on a different access to technology. Second, we inspected the page structure and found even more issues using the experience and knowledge we had. And third, we used tooling to discover further issues and get inspired to explore more. Alex does not like the WAVE Chrome extension too much and rather prefers Axe. However, for this session we decided to go for another option, letting me get to know another feature of the wonderfully useful Chrome DevTools: Lighthouse, allowing you to run audits for accessibility. The report provided an overall score, automatically detected issues and their instances, as well as a useful checklist of what to explore for as it could not be detected manually. Super easy, fast and really worth it.
As I can really recommend to try this demo app on your own, I won't list our findings directly here in this blog post. If you'd like to compare your results with ours then check out our mind map of potential issues. In the end, we compared them with the provided list of 18 accessibility issues and found that we had identified a lot of them! At the same time, we learned about many more problems we had not been aware of at all before and solutions we even didn't know existed. Awesome!
Having still 15 minutes to go, we decided to follow our original plan and tackle a productive site as well. We selected agoda, a travel booking platform. Having only a very limited time box, we decided to instantly use Lighthouse and discovered the page's score was not much higher than the one of the inaccessible practice app. This way we found so many issues very quickly already. We also stumbled across other usability issues like changing navigation or not responsive design. Last but not least we tried to tab through the homepage which offered a navigation menu and a form to book a hotel room - and here's what happened. Just try it yourself!
What can I say? We had a blast while discussing our experiences, sharing our accessibility knowledge and finding issue over issue! First, we looked for quick wins using our eyes (we're biased beings), things that instantly stood out that we knew could cause trouble for people who have to rely on a different access to technology. Second, we inspected the page structure and found even more issues using the experience and knowledge we had. And third, we used tooling to discover further issues and get inspired to explore more. Alex does not like the WAVE Chrome extension too much and rather prefers Axe. However, for this session we decided to go for another option, letting me get to know another feature of the wonderfully useful Chrome DevTools: Lighthouse, allowing you to run audits for accessibility. The report provided an overall score, automatically detected issues and their instances, as well as a useful checklist of what to explore for as it could not be detected manually. Super easy, fast and really worth it.
As I can really recommend to try this demo app on your own, I won't list our findings directly here in this blog post. If you'd like to compare your results with ours then check out our mind map of potential issues. In the end, we compared them with the provided list of 18 accessibility issues and found that we had identified a lot of them! At the same time, we learned about many more problems we had not been aware of at all before and solutions we even didn't know existed. Awesome!
Having still 15 minutes to go, we decided to follow our original plan and tackle a productive site as well. We selected agoda, a travel booking platform. Having only a very limited time box, we decided to instantly use Lighthouse and discovered the page's score was not much higher than the one of the inaccessible practice app. This way we found so many issues very quickly already. We also stumbled across other usability issues like changing navigation or not responsive design. Last but not least we tried to tab through the homepage which offered a navigation menu and a form to book a hotel room - and here's what happened. Just try it yourself!
- For the first few tabs we saw where we were as navigation menu elements showed a blue highlighting frame.
- The next few tabs suddenly did not show anymore any focus, so we got lost.
- The next tab opened the calendar for the arrival date at the hotel - strange, as we had skipped the first form element to enter a destination.
- We tabbed to the second calendar for the departure date, tabbed again and landed in a sort of drop-down / dialog / sub-form / whatever element to provide the number of rooms, adults and children.
- We tabbed on. And found ourselves trapped in this very UI element! We could neither tab forward nor backward.
Looking Back
As for each pairing session, we took some time in the end to reflect on what we learned and share our thoughts. First of all: The demo app was a really valuable target to explore, it raised awareness of the multiple traps to fall into when it comes to accessibility. Interestingly, we noticed we didn't even look at the accessible version of the page to see an example how to do it well! This is definitely still worth looking into. In any case, we both loved our approach of first practicing with the demo app, getting our brains prepared, and then switching to a productive application, being instantly able to spot issues there with the knowledge gained. We identified a lot within only 15 minutes - time worth spent.
It turned out again that bad accessibility design is often also bad user experience for everyone. Designing accessible sites improves the experience for everyone else as well. However, accessibility has to be considered already during design. Nowadays there are so many tools to support us, like checking for sufficient color contrast already in mockups.
Talking about our collaboration, it was once again a very easy session for both of us. We had agreed to use strong-style pairing and a mob timer to frequently switch roles. Alex also had made some experience with this approach already and felt comfortable with it. Our flow was very natural. Especially one fact caught our eye: we followed up on each other's ideas, using the "yes, and ..." rule from improvisational theater. Alex had already noticed that ignoring this is a common problem when pairing. In all the sessions I did on my testing tour, I found this to be one of the most important key points to pair successfully with strangers, being productive from the first minute on.
The session was thoughtful. It was super productive. It was so relevant for Alex' current project, where accessibility is a big part of the testing strategy. And the session was fun! Like several others before him, also Alex advised to "do it with someone else" as this makes it so much easier. "Don't test alone, for your own safety." I have nothing to add.
We had a blast! Had a wonderful #PairTesting session with @cyber_decker on #accessibility, finding so many issues within short time & learning about problems we weren't aware of before. "Don't test alone, for your own safety." Thank you Alex for joining me on my #TestingTour! 😃— Elisabeth Hocke (@lisihocke) October 5, 2018
No comments:
Post a Comment