Danielle Bonanni - Product Design and UX

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...

Today I finally bit the bullet and focused on creating a page on the practice site that would allow me to practice with form components, and live events based on actions. I have the basics down thanks to a friend of mine who walked me through the tools and resources that would be best for this very specific scenario and wrote the skeleton of the page that I could edit to make more accessible. She recommended using JQuery and JavaScript to avoid requiring a database or AJAX. Thanks to w3school.com for their amazing resources. My goal is to make the form fields clear on each submit, and post the data in a styled way on the page. I'd also like to make each submit speak a "success" message to alert the user of the new content, and of course, add labels to everything. Since this took the entire day, it will have to do for now. Luckily there are built-in focus states for the input and button elements by default. This was a productive day, but I may need to take a walk after ...

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...