Danielle Bonanni - Product Design and UX

It can be daunting to look at an entire platform and be told, "Ok, now make it accessible." You don't need revolutionary planning, or exhaustive sprints to start. Including some accessibility work into regular sprint planning can offset any extra LOE, and you can start adding accessibility requirements right into each ticket. In a blog post for MediSked that I wrote in 2021, " Modular Accessibility for All Users ", I outline some easy ways to incorporate real accessibility into the SDLC, and start making progress to a completely accessible product as a whole. Some of the basics include: Using a third-party library of components that have accessibility built in. (Like Kendo UI for VUE or Deque Code Library )You'll still need to adjust and apply them right, but it will get you most of the way there. Include it in every ticket. Link to specific areas that apply to that ticket so engineers and testers know what to focus on. You can link right to the Deque chec...

Long story-short, the winner is JAWS. It's standard key commands are familiar and similar enough to the other screen readers, it has the power to be incredibly customized to your needs if you want but doesn't require it to use, and it's the most supported tool generally. JAWS on Windows with Chrome  Liked: having more options to pull up lists of specific elements to navigate the ability to customize my experience more so that it's catered to my preferences Disliked: Not much really, but it's not free Favorite Key Commands: Q : to skip to main region and start reading the content CTRL + INS + down arrow : to start reading where my last focus was when I needed to pause and take notes on something INS + F6 : find the spot on the page I wanted to read based on the headings instead of having to tab around Narrator on Windows with Edge Liked:  Generally easy to use and navigate Disliked: It doesn't have the same robust list options as JAWS that make viewing a list of ...

Today's focus was on dynamic content, AJAX, and single-page applications. The most relevant topic to my career was how best to notify users of changes when designing interactions related to filling out, validating, and editing forms that post to large data tables to run reports. Three major methods were mentioned, and I wanted to go through each to better define their real-world relevance, provide a specific example, and an additional short-list of scenarios that would be good and bad in which to be used. Method 1: Load a New Page or Reload Current Page Loading a page or reloading the same page to display new content would allow the screen reader user to start reading the entire page again from the top. This is why it's important to keep a status/summary in the title to help assess the page before tabbing through it. Best scenarios for this use: the form I submitted requires the page to refresh in order to display the information I just entered the information I just entered wa...

While reading about keyboard input methods and learning about the success criteria requiring custom keyboard instructions for any custom key commands, one method of accomplishing this was using a tool tip to present the instructions. It mentioned that the tooltip would have to be accessible via keyboard navigation and be able to be read by a screen reader. That reminded me that on my practice site, I spent a significant amount of time creating an example of success criteria for 3.1.3 to provide a definition of an unusual word when the user hovers over the text "affordance" displaying in a tooltip. I did not, however, make this accessible to keyboard-only users or screen readers. Turns out it wasn't even focusable until I gave it a tab index. More investigation into ARIA Practices for 3.24 Tooltip Widget call out specifically that the tooltip container requires role="tooltip" (which I did not have), and the element triggering the tooltip references the tooltip ...

 While reading through the Operable Principles, I admit that I was confused about the success criteria around pointer cancellation . The success criteria states, For functionality that can be operated using a single pointer, at least one of the following is true: No Down-Event: The down-event of the pointer is not used to execute any part of the function Abort or Undo: Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion Up Reversal: The up-event reverses any outcome of the preceding down-event Essential: Completing the function on the down-event is essential Some of my initial questions when reading this are: It mentions functionality using a single pointer, but what are the other options? Is there a double pointer? Do they mean that when they release the down-click the user is prompted to abort the action or undo?  Are they holding down a mouse button reading something tha...

I've spent the months of October and November working through a VPAT and learned a lot.  Getting back into the prep-course material, I'm currently working through the Multi-media and Animation module. While most of the information on captions/transcripts/audio descriptions and audio-video topics don't apply directly to my day-to-day user experience requests, the topic of the parallax effect was interesting enough that I wanted to capture a few notes on it. A colleague recently shared a link to WebFlow.com in reference to designer resources for easily creating web content. This particular link was a scrolling page that illustrated very flashy animations that were available using this service, that you could easily customize if you had their product. It was littered with animations using the parallax effect. Personally, I feel like the current trend for informational websites being large one-page scrolling image galleries not ideal. This particular page was not only that, b...

I recently went about completing my first Voluntary Product Accessibility Template (VPAT) and wanted to write down a few notes on what I experienced. If you want to test your hand at what about the WCAG success criteria you know without having to look it up, this is a great way to quiz yourself in the context of a real example.  First Steps: I downloaded and read the whole thing copy-pasted the instructions into a new Word doc so I could reference it easily and focus on the final product being its own thing filled out the title page removed sections that did not apply to the product I was filling it out for Things I learned: The easiest way to complete one is by first having some form of accessibility audit done on the platform to help address and break down problem areas In the VPAT instructions, it says to break out a product into multiple reports that cover similar functionality if the product is too large or too complex for one report. However, some advice I was given from tho...

 Something that makes it difficult to fully understand the WCAG principles is having a realistic example of how they'd be applied. What I've found is that some apply to only a small or specific scenario or type of web content. I thought it would be helpful to go through and identify which would apply to common content, and which would be specific. For the sake of this exercise, a "common" web content type would be a standard marketing website, blog, or other sites with simple text content and maybe a web form or two. Ultra-Applicable: These I'd consider basically apply to everything and are the component level to allow basic functionality. 2.1 Keyboard Accessible Everyone needs to be able to navigate and use the site without requiring a mouse or touch screen 2.4 Navigable Users should be able to tab through a main nav list of links, or through a search function, or from contextual page links to get to where they want to go. Niche Functionality or Industry Specific...

I'm taking a break from working through the Deque prep-course modules and learning new key commands for JAWS. Instead, I'm returning to the written WCAG 2.1 specs to better understand their details. To better understand each of the success criteria, I've written out a realistic scenario in which each of the success criteria would apply to accomplish the task. This scenario focuses on the  Operable  principle and encompass all aspects of the user being able to interact with elements digitally, use devices like keyboards, and other aspects of navigation and interaction that may physically affect the user. Scenario: COVID Survey without a Mouse or Trackpad In this scenario, my BlueTooth mouse is not functioning, and my laptop trackpad is locked. I can only use my keyboard and need to complete a COVID survey before going into our shared office space for work. I need to be able to tab through the desktop to get to Chrome, then tab through the website to find the right page to fi...

I went down a rabbit hole for a little bit into the realm of icon fonts. I personally feel that they solve a series of problems from a UX designer perspective, and was interested in the conversations around the strong opinions as to why they should be avoided. To sum up the conclusion, as with any problem with implementing a user experience or accessibility solution, the answer indomitably is "it depends." It all depends on how you're using them, who your users are, what your "product" is, and other technology you may have to accommodate to. In the article " Seriously, Don't Use Icon Fonts " by Tyler Sticka , he lists some strong arguments against fonts, and for SVG's; such as: Font Icons may not display the correct icon, or display at all, depending on browser compatibility or if the user has selected to use a specific font such as OpenDyslexic Screen readers read out the font icon if it's not hidden They don't allow for multi-color or...

I'm currently working through the "Images, SVG, and Canvas" module of the Deque University WAS prep-course, and I'm surprised by how specific and helpful the information is. There's a lot more than just adding alt text to images. The big revelations dealt with image maps, visuals that would require excessive explanation not appropriate for an alt text, images instead of buttons, geographical maps, and text alternatives for data visualizations. Image Maps Firstly, I completely forgot that image maps were a thing. I vaguely remember abusing this option when making a websites in the early 2000 because it allowed you to simply identify hot spots as links on a robust image background instead of dealing with HTML buttons, or actual code.  If you're unable to use a more appropriate solution than an image map, you'd need to: provide alt text on the background image to summarize the context of the area alt text provide alt text describing the map area within that c...