{"id":260,"date":"2024-04-25T12:00:00","date_gmt":"2024-04-25T12:00:00","guid":{"rendered":"http:\/\/suimy.me\/?p=260"},"modified":"2024-05-01T17:00:34","modified_gmt":"2024-05-01T17:00:34","slug":"conducting-accessibility-research-in-an-inaccessible-ecosystem","status":"publish","type":"post","link":"http:\/\/suimy.me\/index.php\/2024\/04\/25\/conducting-accessibility-research-in-an-inaccessible-ecosystem\/","title":{"rendered":"Conducting Accessibility Research In An Inaccessible Ecosystem"},"content":{"rendered":"<p>              <title>Conducting Accessibility Research In An Inaccessible Ecosystem<\/title><\/p>\n<article>\n<header>\n<h1>Conducting Accessibility Research In An Inaccessible Ecosystem<\/h1>\n<address>Michele Williams<\/address>\n<p>                  2024-04-25T12:00:00+00:00<br \/>\n                  2024-05-01T16:05:07+00:00<br \/>\n                <\/header>\n<p>Ensuring technology is accessible and inclusive relies heavily on receiving feedback directly from disabled users. You cannot rely solely on checklists, guidelines, and good-faith guesses to get things right. This is often hindered, however, by a lack of accessible prototypes available to use during testing.<\/p>\n<p>Rather than wait for the digital landscape to change, researchers should leverage all the available tools they can use to create and replicate the testing environments they need to get this important research completed. Without it, we will continue to have a primarily inaccessible and not inclusive technology landscape that will never be disrupted.<\/p>\n<p><strong>Note<\/strong>: <em>I use \u201cidentity first\u201d disability language (as in \u201cdisabled people\u201d) rather than \u201cpeople first\u201d language (as in \u201cpeople with disabilities\u201d). Identity first language aligns with disability advocates who see disability as a human trait description or even community and not a subject to be avoided or shamed. For more, review \u201c<a href=\"https:\/\/www.nih.gov\/about-nih\/what-we-do\/science-health-public-trust\/perspectives\/writing-respectfully-person-first-identity-first-language\">Writing Respectfully: Person-First and Identity-First Language<\/a>\u201d.<\/em><\/p>\n<h2 id=\"accessibility-focused-research-in-all-phases\">Accessibility-focused Research In All Phases<\/h2>\n<p>When people advocate that UX Research should include disabled participants, it\u2019s often with the mindset that this will happen on the final product once development is complete. One primary reason is because that\u2019s when researchers have access to <em>the most<\/em> accessible artifact with which to run the study. However,<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aThe%20real%20ability%20to%20ensure%20an%20accessible%20and%20inclusive%20system%20is%20not%20by%20evaluating%20a%20final%20product%20at%20the%20end%20of%20a%20project;%20it%e2%80%99s%20by%20assessing%20user%20needs%20at%20the%20start%20and%20then%20evaluating%20the%20iterative%20prototypes%20along%20the%20way.%20%0a&amp;url=https:\/\/smashingmagazine.com%2f2024%2f04%2fconducting-accessibility-research-inaccessible-ecosystem%2f\"><\/p>\n<p>The real ability to ensure an accessible and inclusive system is not by evaluating a final product at the end of a project; it\u2019s by assessing user needs at the start and then evaluating the iterative prototypes along the way. <\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<h3 id=\"prototype-research-should-include-disabled-participants\">Prototype Research Should Include Disabled Participants<\/h3>\n<p>In general, the iterative prototype phase of a project is when teams explore various design options and make decisions that will influence the final project outcome. Gathering feedback from representative users during this phase can help teams make informed decisions, including key pivots before significant development and testing resources are used.<\/p>\n<p>During the prototype phase of user testing, the representative users should include disabled participants. By collecting feedback and perspectives of people with a variety of disabilities in early design testing phases, teams can more thoughtfully incorporate key considerations and supplement accessibility guidelines with real-world feedback. This <strong>early-and-often approach<\/strong> is the best way to include accessibility and inclusivity into a process and ensure a more accessible final product.<\/p>\n<p>If you instead wait to include disabled participants in research until a product is near final, this inevitably leads to patchwork fixes of any critical feedback. Then, for feedback not deemed critical, it will likely get \u201cbacklogged\u201d where <strong>the item priorities compete with new feature updates<\/strong>. With this approach, you\u2019ll constantly be playing catch-up rather than getting it right up front and in an elegant and integrated way.<\/p>\n<h3 id=\"accessibility-research-can-t-wait-until-the-end\">Accessibility Research Can\u2019t Wait Until The End<\/h3>\n<p>Not only does research with disabled participants often occur too late in a project, but it is also far too often viewed as separate from other research studies (sometimes referred to as the \u201cmain research\u201d). It cannot be understated that this reinforces the <strong>notion of separate-and-not-equal<\/strong> as compared to non-disabled participants and other stakeholder feedback. This has a severe negative impact on how a team will view the priority of inclusive design and, more broadly, the value of disabled people. That is, this reinforces \u201c<a href=\"https:\/\/www.accessliving.org\/newsroom\/blog\/ableism-101\/\">ableism<\/a>\u201d, a devaluing of disabled people in society.<\/p>\n<blockquote class=\"pull-quote\">\n<p>\n    <a class=\"pull-quote__link\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=%0aUX%20Research%20with%20diverse%20participants%20that%20include%20a%20wide%20variety%20of%20disabilities%20can%20go%20a%20long%20way%20in%20dismantling%20ableist%20views%20and%20creating%20vitally%20needed%20inclusive%20technology.%0a&amp;url=https:\/\/smashingmagazine.com%2f2024%2f04%2fconducting-accessibility-research-inaccessible-ecosystem%2f\"><\/p>\n<p>UX Research with diverse participants that include a wide variety of disabilities can go a long way in dismantling ableist views and creating vitally needed inclusive technology.<\/p>\n<p>    <\/a>\n  <\/p>\n<div class=\"pull-quote__quotation\">\n<div class=\"pull-quote__bg\">\n      <span class=\"pull-quote__symbol\">\u201c<\/span><\/div>\n<\/p><\/div>\n<\/blockquote>\n<p>The problem is that even when a team is on board with the idea, it\u2019s not always easy to do inclusive research, particularly when involving prototypes. While discovery research can be conducted with minimal tooling and summative research can leverage fully built and accessible systems, prototype research quickly reveals severe accessibility barriers that feel like they can\u2019t be overcome.<\/p>\n<div data-audience=\"non-subscriber\" data-remove=\"true\" class=\"feature-panel-container\">\n<aside class=\"feature-panel\">\n<div class=\"feature-panel-left-col\">\n<div class=\"feature-panel-description\">\n<p>Meet <strong><a data-instant href=\"\/printed-books\/touch-design-for-mobile-interfaces\/\">Touch Design for Mobile Interfaces<\/a><\/strong>, Steven Hoober\u2019s brand-new guide on <strong>designing for mobile<\/strong> with proven, universal, human-centric guidelines. <strong>400 pages<\/strong>, jam-packed with in-depth user research and <strong>best practices<\/strong>.<\/p>\n<p><a data-instant href=\"https:\/\/www.smashingmagazine.com\/printed-books\/touch-design-for-mobile-interfaces\/\" class=\"btn btn--green btn--large\">Jump to table of contents\u00a0\u21ac<\/a><\/div>\n<\/div>\n<div class=\"feature-panel-right-col\"><a data-instant href=\"https:\/\/www.smashingmagazine.com\/printed-books\/touch-design-for-mobile-interfaces\/\" class=\"feature-panel-image-link\"><\/p>\n<div class=\"feature-panel-image\">\n<img loading=\"lazy\" class=\"feature-panel-image-img lazyload\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Feature Panel\" width=\"480\" height=\"697\" data-src=\"https:\/\/archive.smashing.media\/assets\/344dbf88-fdf9-42bb-adb4-46f01eedd629\/b14658fc-bb2d-41a6-8d1a-70eaaf1b8ec8\/touch-design-book-shop-opt.png\"><\/p>\n<\/div>\n<p><\/a>\n<\/div>\n<\/aside>\n<\/div>\n<h2 id=\"inaccessible-technology-impedes-accessibility-research\">Inaccessible Technology Impedes Accessibility Research<\/h2>\n<p>Most technology we use has accessibility barriers for users with disabilities. As an example, <a href=\"https:\/\/webaim.org\/projects\/million\/\">the WebAIM Million report<\/a> consistently finds that <strong>96% of web homepages have accessibility errors<\/strong> that are fixable and preventable.<\/p>\n<p>Just like websites, web, and mobile applications are similarly inaccessible, including those that produce early-stage prototypes. Thus, the artifacts researchers might want to use for prototype testing to help create accessible products are themselves inaccessible, creating a barrier for disabled research participants. It quickly becomes a vicious cycle that seems hard to break.<\/p>\n<h3 id=\"the-limitations-of-figma\">The Limitations Of Figma<\/h3>\n<p>Currently, the most popular industry tool for initial prototyping is Figma. These files become the artifacts researchers use to conduct a research study. However, these files often fall short of being accessible enough for many participants with disabilities.<\/p>\n<p>To be clear, I absolutely applaud the Figma employees who have worked very hard on including <a href=\"https:\/\/help.figma.com\/hc\/en-us\/articles\/7810391964695-Accessible-prototypes-in-Figma\">screen reader support and keyboard functionality in Figma prototypes<\/a>. This represents significant progress towards removing accessibility barriers in our core products and should not be overlooked. Nevertheless, there are still limitations and even blockers to research.<\/p>\n<p>For one, the Figma files must be created in a way that will mimic the website layout and code. For example, for screen reader navigation to be successful, <strong>the elements need to be in their correct reading order in the Layers panel<\/strong> (not solely look correct visually), include <strong>labeled elements such as buttons<\/strong> (not solely items styled to look like buttons), and include <strong>alternative text for images<\/strong>. Often, however, designers do not build iterative prototypes with these considerations in mind, which prevents the keyboard from navigating correctly and the screen reader from providing the necessary details to comprehend the page.<\/p>\n<p>In addition, Figma\u2019s prototypes do not have selectable, configurable text. This prevents key visual adjustments such as browser zoom to increase text size, dark mode, which is easier for some to view, and selecting text to have it read aloud. If a participant needs these kinds of adjustments (or others I list in the table below), a Figma prototype will not be accessible to them.<\/p>\n<p><strong>Table:<\/strong> Figma prototype limitations per assistive technology<\/p>\n<table class=\"tablesaw break-out\">\n<thead>\n<tr>\n<th>Assistive Technology<\/th>\n<th>Disability Category<\/th>\n<th>Limitation<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Keyboard-only navigation<\/td>\n<td>Mobility<\/td>\n<td>Must use proper element type (such as button or input) in expected page order to ensure operability<\/td>\n<\/tr>\n<tr>\n<td>Screen reader<\/td>\n<td>Vision<\/td>\n<td>Must include structure to ensure readability:<\/p>\n<ul>\n<li>Including elements in logical order to ensure correct reading order<\/li>\n<li>Alternative text added to images<\/li>\n<li>Descriptive names added for buttons<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<tr>\n<td>Dark mode\/High contrast mode<\/td>\n<td>Low Vision<br \/>Neurodiversity<\/td>\n<td>Not available<\/td>\n<\/tr>\n<tr>\n<td>Browser zoom<\/td>\n<td>Low Vision<br \/>Neurodiversity<br \/>Mobility<\/td>\n<td>Not available<\/td>\n<\/tr>\n<tr>\n<td>Screen reader used with mouse hover<br \/>Read aloud software with text selection<\/td>\n<td>Vision<br \/>Neurodiversity<\/td>\n<td>Cannot be used<\/td>\n<\/tr>\n<tr>\n<td>Voice control<br \/>Switch control device<\/td>\n<td>Mobility<\/td>\n<td>Cannot be used<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h3 id=\"inclusive-research-is-needed-regardless\">Inclusive Research Is Needed Regardless<\/h3>\n<p>Having accessibility challenges with a prototype doesn\u2019t mean we give up on the research. Instead, it means <strong>we need to get creative in our approach<\/strong>. This research is too important to keep waiting for the ideal set-up, particularly when our findings are often precisely what\u2019s needed to create accessible technology.<\/p>\n<p>Part of crafting a research study is determining what artifact to use during the study. Thus, when considering prototype research, it is a matter of creating the artifact best suited for your study. If this isn\u2019t going to be, say, a Figma file you receive from designers, then consider what else can be used to get the job done.<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"working-around-the-current-state\">Working Around the Current State<\/h2>\n<p>Being able to include diverse perspectives from disabled research participants throughout a project\u2019s creation is possible and necessary. Keeping in mind your research questions and the capabilities of your participants, there are research methods and strategies that can be made accessible to gather authentic feedback during the critical prototype design phase.<\/p>\n<p>With that in mind, I propose five ways you can accomplish prototype research while working around inaccessible prototypes:<\/p>\n<ol>\n<li><a href=\"#use-a-survey-instead\">Use a survey.<\/a><\/li>\n<li><a href=\"#conduct-co-design-sessions\">Conduct a co-design session.<\/a><\/li>\n<li><a href=\"#test-with-an-equivalent-system\">Test with a similar system.<\/a><\/li>\n<li><a href=\"#build-a-rapid-website-prototype\">Build your own rapid prototype.<\/a><\/li>\n<li><a href=\"#use-wizard-of-oz\">Use the Wizard of Oz method.<\/a><\/li>\n<\/ol>\n<h3 id=\"use-a-survey-instead\">Use a Survey Instead<\/h3>\n<p>Not all research questions at this phase need a full working prototype to be answered, particularly if they are about the general product features or product wording and not the visual design. Oftentimes, a survey tool or similar type of evaluation can be just as effective.<\/p>\n<p>For example, you can confirm a site\u2019s navigation options are intuitive by describing a scenario with a list of navigation choices while also testing if key content is understandable by confirming the user\u2019s next steps based on a passage of text.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/example-survey.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"602\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Sample survey for Acme Company that tests their key site wording. Full survey wording is included below.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/example-survey.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Consider testing content in a survey format. (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/example-survey.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<div class=\"js-table-accordion accordion book__toc\" id=\"TOC\">\n<dl class=\"accordion-list\" style=\"margin-bottom: 1em\" data-handler=\"Accordion\">\n<dt class=\"accordion-item\" id=\"accordion-item-0\">\n<div class=\"book__toc__accordion-text\">\n<div class=\"book__toc__chapter-col chapter__title\">\n                  Image description\n                <\/div>\n<\/p><\/div>\n<div class=\"accordion-expand-btn-wrapper\">\n                  <span class=\"accordion-expand-btn js-accordion-expand-btn\">+<\/span>\n              <\/div>\n<\/dt>\n<dd class=\"accordion-desc\" id=\"accordion-desc-0\" aria-hidden=\"true\">\n<div class=\"book__toc__chapter-col chapter__summary\">\n<p>Acme Company Website Survey<\/p>\n<p>Complete this questionnaire to help us determine if our site will be understandable.<\/p>\n<ol>\n<li>Scenario: You want to find out this organization&#8217;s mission statement. Which menu option do you choose?<br \/>[List of radio buttons]\n<ul>\n<li>Home<\/li>\n<li>About<\/li>\n<li>Resources<\/li>\n<li>Find an Office<\/li>\n<li>Search<\/li>\n<\/ul>\n<\/li>\n<li>The following describes directions for applying to our grant. After reading, answer the following question:\n<p>The Council\u2019s Grant serves to advance Acme&#8217;s goals by sponsoring community events. In determining whether to fund an event, the Council also considers factors including, but not limited to:<\/p>\n<ul>\n<li>Target audiences<\/li>\n<li>Alignment with the Council\u2019s goals and objectives<\/li>\n<li>Evaluations measuring participant satisfaction<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p>To apply, download the form below.<\/p>\n<p>Based on this wording, what would you include in your grant application?<br \/>[Input Field]\n             <\/div>\n<\/dd>\n<p>     <span><\/span><\/dl>\n<\/div>\n<p>Just be sure you build a WCAG-compliant survey that includes accessible form layouts and question types. This will ensure participants can navigate using their assistive technologies. For example, <a href=\"https:\/\/www.qualtrics.com\/support\/survey-platform\/survey-module\/survey-tools\/check-survey-accessibility\/\">Qualtrics<\/a> has a specific form layout that is built to be accessible, or check out these <a href=\"https:\/\/accessibility.wfu.edu\/resources\/accessible-google-forms\/\">accessibility tips for Google Forms<\/a>. If sharing a document, note features that will enhance accessibility, such as using the ribbon for styling in <a href=\"https:\/\/support.microsoft.com\/en-us\/office\/make-your-word-documents-accessible-to-people-with-disabilities-d9bf3683-87ac-47ea-b91a-78dcacb3c66d\">Microsoft Word<\/a>.<\/p>\n<p><strong>Tip<\/strong>: <em>To find accessibility documentation for the software you\u2019re using, search in your favorite search engine for the product name plus the word \u201caccessibility\u201d to find a product\u2019s accessibility documentation.<\/em><\/p>\n<h3 id=\"conduct-co-design-sessions\">Conduct Co-design Sessions<\/h3>\n<p>The prototyping phase might be a good time to utilize <a href=\"https:\/\/uxmag.com\/articles\/creativity-based-research-the-process-of-co-designing-with-users\">co-design and participatory design methods<\/a>. With these methods, you can co-create designs with participants using any variety of artifacts that match the capabilities of your participants along with your research goals. The feedback can range from high-level workflows to specific visual designs, and you can guide the conversation with mock-ups, equivalent systems, or more creative artifacts such as <a href=\"https:\/\/www.interaction-design.org\/literature\/article\/ux-storyboards\">storyboards<\/a> that illustrate a scenario for user reaction.<\/p>\n<p>For the prototype artifacts, these can range from low- to high-fidelity. For instance, participants without mobility or vision impairments can use paper-and-pencil sketching or whiteboarding. People with somewhat limited mobility may prefer a tablet-based drawing tool, such as using an Apple pencil with an iPad. Participants with visual impairments may prefer more 3-dimensional tools such as craft supplies, modeling clay, and\/or cardboard. Or you may find that simply working on a collaborative online document offers the best accessibility as users can engage with their personalized assistive technology to jot down ideas.<\/p>\n<p>Notably, the types of artifacts you use will be beneficial across differing user groups. In fact, rather than limiting the artifacts, <strong>try to offer a variety of ways to provide feedback by default<\/strong>. By doing this, participants can feel more empowered and engaged by the activity while also reassuring them you have created an inclusive environment. If you\u2019re not sure what options to include, feel free to confirm what methods will work best as you recruit participants. That is, as you describe the primary activity when they are signing up, you can ask if the materials you have will be operable for the participant or allow them to tell you what they prefer to use.<\/p>\n<p>The discussion you have and any supplemental artifacts you use then depend on communication styles. For example, deaf participants may need sign language interpreters to communicate their views but will be able to see sample systems, while blind participants will need descriptions of key visual information to give feedback. The actual study facilitation comes down to <strong>who you are recruiting<\/strong> and <strong>what level of feedback you are seeking<\/strong>; from there, you can work through the accommodations that will work best.<\/p>\n<p>I conducted two co-design sessions at two different project phases while exploring how to create a wearable blind pedestrian navigation device. Early in the project, when we were generally talking about the feature set, we brought in several low-fidelity supplies, including a Braille label maker, cardboard, clay, Velcro, clipboards, tape, paper, and pipe cleaners. Based on user feedback, I fashioned a clipboard hanging from pipe cleaners as one prototype.<\/p>\n<p>Later in the project when we were discussing the size and weight, we taped together Arduino hardware pieces representing the features identified by the participants. Both outcomes are pictured below and featured in a paper entitled, \u201c<a href=\"https:\/\/dl.acm.org\/doi\/pdf\/10.1145\/2745555.2746664\">What Not to Wearable: Using Participatory Workshops to Explore Wearable Device Form Factors for Blind Users<\/a>.\u201d<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"554\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Michele is reaching for a prototype from a blind research participant. The artifact is a clip board hanging from the participant&#039;s neck using pipe cleaners taped to the board.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Michele Williams demonstrates a physical prototype constructed based on feedback from members of a visually impaired design team. (Image source: \u201c<a href=\"https:\/\/dl.acm.org\/doi\/pdf\/10.1145\/2566462\">Collaboratively Designing Assistive Technology<\/a>\u201d) (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype-two.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"556\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Three example wearable devices with taped together Arduino hardware. The size of 2 devices is approximately that of an iPod, with one device a small camera and rectangular battery.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype-two.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Creations from two design groups made up of blind participants. Devices feature a camera (detached in one design) and a touchpad made from Arduino pieces. (Image source: \u201c<a href=\"https:\/\/dl.acm.org\/doi\/pdf\/10.1145\/2745555.2746664\">What Not to Wearable: Using Participatory Workshops to Explore Wearable Device Form Factors for Blind Users<\/a>\u201d) (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/co-design-prototype-two.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>Ultimately, the benefit of this type of study is the participant-led feedback. In this way, participants are giving <strong>unfiltered feedback<\/strong> that is less influenced by designers, which may lead to more thoughtful design in the end.<\/p>\n<h3 id=\"test-with-an-equivalent-system\">Test With an Equivalent System<\/h3>\n<p>Very few projects are completely new creations, and often, teams use an existing site or application for project inspiration. Consider using similar existing systems and equivalent scenarios for your testing instead of creating a prototype.<\/p>\n<p>By using an existing live system, participants can then use their assistive technology and adaptive techniques, which can make the study <strong>more accessible and authentic<\/strong>. Also, the study findings can range from the desirability of the available product features to the accessibility and usability of individual page elements. These lessons can then inform what design and code decisions to make in your system.<\/p>\n<p>One caveat is to <strong>be aware of any accessibility barriers in that existing system<\/strong>. Particularly for website and web applications, you can look for accessibility documentation to determine if the company has reported any WCAG-conformance accessibility efforts, use tools like <a href=\"https:\/\/wave.webaim.org\/\">WAVE<\/a> to test the system yourself, and\/or mimic how your participants will use the system with their assistive technology. If there are workarounds for what you find, you may be able to avoid certain parts of the application or help users navigate past the inaccessible parts. However, if the site is going to be completely unusable for your participants, this won\u2019t be a viable option for you.<\/p>\n<p>If the system is usable enough for your testing, however, you can take the testing a step further by making updates on the fly if you or someone you collaborate with has engineering experience. For example, you can manipulate a website\u2019s code with developer tools to add, subtract, or change the elements and styling on a page in real-time. (See \u201c<a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Learn\/Common_questions\/Tools_and_setup\/What_are_browser_developer_tools\">About browser developer tools<\/a>\u201d.) This can further enhance the feedback you give to your teams as it may more closely match your team\u2019s intended design.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/devtools-inspector.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"606\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Screenshot of a browser with developer tools  occupying the bottom half. The main page shows \u2018Mozilla is cool, Irene\u2019 with the Firefox logo, and the logo is selected and highlighted in the dev tool panels.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/devtools-inspector.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Manipulating the Developer Tools can create real-time page updates. (Image source: \u201c<a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Learn\/Common_questions\/Tools_and_setup\/What_are_browser_developer_tools\">What are browser developer tools?<\/a>\u201d) (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/devtools-inspector.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<h3 id=\"build-a-rapid-website-prototype\">Build a Rapid Website Prototype<\/h3>\n<p>Notably, when conducting research focused on physical devices and hardware, you will not face the same obstacles to inaccessibility as with websites and web applications. You can use a variety of materials to create your prototypes, from cardboard to fabric to 3D printed material. I\u2019ve sewn haptic vibration modules to a makeshift leather bracelet when working with wearables, for instance.<\/p>\n<p>However, for web testing, it may be necessary to build a rapid prototype, especially to work around inaccessible artifacts such as a Figma file. This will include using a site builder that allows you to quickly create a replica of your team\u2019s website. To create an accessible website, you\u2019ll need a site builder with accessibility features and capabilities; I recommend <a href=\"https:\/\/wordpress.com\/support\/accessibility\/\">WordPress<\/a>, <a href=\"https:\/\/support.squarespace.com\/hc\/en-us\/articles\/215129127-Accessibility-resources-at-Squarespace\">SquareSpace<\/a>, <a href=\"https:\/\/webflow.com\/accessibility\">Webflow<\/a>, and <a href=\"https:\/\/support.google.com\/sites\/answer\/7529116?hl=en\">Google Sites<\/a>.<\/p>\n<p>I recently used <a href=\"https:\/\/support.google.com\/a\/users\/answer\/9310491?hl=en\">Google Sites<\/a> to create a replica of a client\u2019s draft pages in a matter of hours. I was adamant we should include disabled participants in feedback loops early and often, and this included after a round of significant visual design and content decisions. The web agency building the client\u2019s site used Figma but not with the required formatting to use the built-in screen reader functionality. Rather than leave out blind user feedback at such a crucial time in the project, I started with a similar Google Sites template, took a best guess at how to structure the elements such as headings, recreated the anticipated column and card layouts as best I could, and used placeholder images with projected alt text instead of their custom graphics.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/sample-sites-grouped.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"433\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Side-by-side of the Figma view versus Google Sites view of a site. The Figma file has significantly more visual appeal, including custom fonts, colors, and graphics, while the Google Site is minimal visually but structurally the same.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/sample-sites-grouped.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Comparison of Figma file (left) versus Google Sites website (right) used for blind screen reader user testing. Note that some sections are intentionally blurred due to their potentially sensitive content. (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/sample-sites-grouped.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>The screen reader testing turned into an impromptu co-design session because I could make changes in-the-moment to the live site for the participant to immediately test out. For example, we determined that some places where I used headings were not necessary, and we talked about image alt text in detail. I was able to add specific design and code feedback to my report, as well as share the live site (and corresponding code) with the team for comparison.<\/p>\n<p>The downside to my prototype was that I couldn\u2019t create the exact 1-to-1 visual design to use when testing with the other disabled participants who were sighted. I wanted to gather feedback on colors, fonts, and wording, so I also recruited low vision and neurodiverse participants for the study. However, my data was skewed because those participants couldn\u2019t make the visual adjustments they needed to fully take in the content, such as recoloring, resizing, and having text read aloud. This was unfortunate, but we at least used the prototype to spark discussions of what <em>does<\/em> make a page accessible for them.<\/p>\n<p>You may find you are limited in how closely you can replicate the design based on the tools you use or lack of access to developer assistance. When facing these limitations, consider what is most important to evaluate and <strong>determine if a paired-down version of the site will still give you valuable feedback over no site at all<\/strong>.<\/p>\n<h3 id=\"use-wizard-of-oz\">Use Wizard of Oz<\/h3>\n<p>The Wizard of Oz (WoZ) research method involves the facilitators mimicking system interactions in place of a fully working system. With WoZ, you can create your system\u2019s approximate functionality using equivalent accessible tools and processes.<\/p>\n<p>As an example, I\u2019ll refer you to the talk by an Ally Financial research team that used this method for participants who used screen readers. They pre-programmed screen reader prompts into a clickable spreadsheet and had participants describe aloud what keyboard actions they would take to then trigger the corresponding prompt. While not the ideal set-up for the participants or researchers, it at least brought screen reader user feedback (and recognition of the users themselves) to the early design phases of their work. For more, review their detailed talk \u201c<a href=\"https:\/\/www.youtube.com\/watch?v=lCuK_djeCtg&amp;pp=ygVOYWxseSBmaW5hbmNpYWwgcmVtb3ZpbmcgYmlhcyB3aXRoIHdpemFyZCBvZiBveiBzY3JlZW4gcmVhZGVyIHVzYWJpbGl0eSB0ZXN0aW5n\">Removing bias with wizard of oz screen reader usability testing<\/a>\u201d.<\/p>\n<figure class=\"\n  \n    break-out article__image\n  \n  \n  \"><\/p>\n<p>    <a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/woz-testing.png\"><\/p>\n<p>    <img loading=\"lazy\" width=\"800\" height=\"450\" src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"From the Ally Financial ID24 conference presentation on YouTube, presenter Annabel Weiner is discussing a slide titled, \u2018Building the test\u2019 which details  all possible screen reader feedback under headings such as Headings, Tables, and Landmarks.\" class=\"lazyload\" data-src=\"https:\/\/res.cloudinary.com\/indysigner\/image\/fetch\/f_auto,q_80\/w_400\/https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/woz-testing.png\"><\/p>\n<p>    <\/a><figcaption class=\"op-vertical-bottom\">\n      Listing the anticipated screen reader feedback is the start of using WoZ for simulated prototype navigation. (Image Source: <a href=\"https:\/\/www.youtube.com\/watch?v=lCuK_djeCtg\">Removing Bias with Wizard of Oz Screen Reader Usability Testing<\/a>) (<a href=\"https:\/\/files.smashing.media\/articles\/conducting-accessibility-research-inaccessible-ecosystem\/woz-testing.png\">Large preview<\/a>)<br \/>\n    <\/figcaption><\/figure>\n<p>This isn\u2019t just limited to screen reader testing, however. In fact, I\u2019ve also often used Wizard of Oz for Voice User Interface (VUI) design. For instance, when I helped create an Alexa \u201cskill\u201d (their name for an app on Amazon speech-enabled devices), our prototype wouldn\u2019t be ready in time for user testing. So, I drafted an idea to use a Bluetooth speaker to announce prompts from a clickable spreadsheet instead. When participants spoke a command to the speaker (thinking it was an Alexa device), the facilitator would select the appropriate pre-recorded prompt or a generic \u201cI don\u2019t understand\u201d message.<\/p>\n<p>Any system can be mimicked when you break down its parts and pieces and think about the ultimate interaction for the user. Creating WoZ set-ups can take creativity and even significant time to put together, but the outcomes can be worth it, particularly for longer-term projects. Once the main pieces are created, the prototype set-up can be edited and reused indefinitely, including during the study or between participants. Also, the investment in an easily edited prototype pays off exponentially if it uncovers something prior to finishing the entire product. In fact, that\u2019s the main goal of this phase of testing: <strong>to help teams know what to look out for before they go through the hard work of finishing the product<\/strong>.<\/p>\n<div class=\"partners__lead-place\"><\/div>\n<h2 id=\"inclusive-research-can-no-longer-wait\">Inclusive Research Can No Longer Wait<\/h2>\n<p>Much has been documented about inclusive design to help teams craft technology for the widest possible audience. From the <a href=\"https:\/\/www.w3.org\/WAI\/standards-guidelines\/wcag\/\">Web Content Accessibility Guidelines<\/a> that help define what it means to be accessible to the <a href=\"https:\/\/inclusive.microsoft.design\/\">Microsoft Inclusive Design Toolkits<\/a> that tell the human stories behind the guidelines, there is much to learn even before a product begins.<\/p>\n<p>However, the best approach is with <strong>direct user feedback<\/strong>. With this, we must recognize the conundrum many researchers are facing: We want to include disabled participants in UX research prior to a product being complete, but often, prototypes we have available for testing are inaccessible. This means testing with something that is essentially broken and will negatively impact our findings.<\/p>\n<p>While it may feel like researchers will always be at a disadvantage if we don\u2019t have the tools we need for testing, I think, instead, it\u2019s time for us to push back. I propose we do this on two fronts:<\/p>\n<ol>\n<li>We make the research work as best we can in the current state.<\/li>\n<li>We advocate for the tools we need to make this more streamlined.<\/li>\n<\/ol>\n<p>The key is to <strong>get disabled perspectives on the record and in the dataset of team members making the decisions<\/strong>. By doing this, hopefully, we shift the culture to wanting and valuing this feedback and bringing awareness to what it takes to make it happen.<\/p>\n<p>Ideally, the awareness raised from our bootstrap efforts will lead to more people helping reduce the current prototype barriers. For some of us, this means urging companies to prioritize accessibility features in their roadmaps. For those working within influential prototype companies, it can mean getting much-needed backing to innovate better in this area.<\/p>\n<p>The current state of our inaccessible digital ecosystem can sometimes feel like an entanglement too big to unravel. However, we must remain steadfast and insist that this does not remain the status quo; <strong>disabled users are users<\/strong>, and their diverse and invaluable perspectives must be a part of our research outcomes at all phases.<\/p>\n<div class=\"signature\">\n  <img src=\"data:image\/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==\" alt=\"Smashing Editorial\" width=\"35\" height=\"46\" loading=\"lazy\" class=\"lazyload\" data-src=\"https:\/\/www.smashingmagazine.com\/images\/logo\/logo--red.png\"><br \/>\n  <span>(yk)<\/span>\n<\/div>\n<\/article>\n","protected":false},"excerpt":{"rendered":"<p>Conducting Accessibility Research In An Inaccessible Ecosystem Conducting Accessibility Research In An Inaccessible Ecosystem Michele Williams 2024-04-25T12:00:00+00:00 2024-05-01T16:05:07+00:00 Ensuring technology [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[12],"tags":[],"_links":{"self":[{"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/posts\/260"}],"collection":[{"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/comments?post=260"}],"version-history":[{"count":1,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/posts\/260\/revisions"}],"predecessor-version":[{"id":261,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/posts\/260\/revisions\/261"}],"wp:attachment":[{"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/media?parent=260"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/categories?post=260"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/suimy.me\/index.php\/wp-json\/wp\/v2\/tags?post=260"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}