Danielle Bonanni - Product Design and UX

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

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

Since I learn better by doing, I chose to use as much of the assistive technologies as possible. So I'm going through the online prep course partially blind.  This is my first real, extensive use of screen readers to interact with web content outside of a text to speech tool to read digital books. I have very strong prescription glasses, and without them have extreme vision impairment. To learn more about the screen readers intimately, I remove my glasses and navigate with keyboard only through the Deque prep course pages, and the browser. Part of being able to apply good user experience is being able to feel the users frustrations and use that to better inform design decisions. This has been frustrating as a new user, but getting more and more familiar. Things I like about it: I appreciate that it calls things out when they are misspelled as I type. I'm glad I can better understand it at a much faster speed now. I'm more familiar with the key commands and feel comfortable ...

This study session focused on the Perceivable goals outlined in the WCAG, and followed Day 2 & Day 3 of the 100 Days of A11y blog. Summary Being "perceivable" is defined as: information and user interface components must be presentable to users in ways they can perceive. Applied to web content, that means any and all content should be "visible" regardless of assistive technologies, user preferences for text sizes, written vs audio vs video preferences, color settings, and screen size/zoom (also closely relates to the robust principle). At first this seems fairly obvious, but it's easy to miss certain considerations if you don't run into them regularly. As an ideal, for example, with any embedded video, you should provide at the very least captioning on the video. To take it a step further, a downloadable transcript would allow someone who may read faster than can listen the ability to read at their own preferred pace, or get the same information from ...

I had a lot of fun getting my hosting and domain and FTP setup as I've been out of that game for a long time. I added my practice site as a link in my main nav of this blog. I plan to add to the site as I work through learning the specific techniques and success criteria that's listed in the WCAG. I'd like to create a way to see the evolution of the site over time too as if it were a progressive web app, but we'll see how ambitious of a goal that is. So far I have: setup my practice site outlined the 100 Days of A11y posts into Trello cards to address individually and follow the path that Amy Carney took outlined the table of contents for the BOK into Trello cards so I can highlight and address ones I need to focus on specifically completed the first module of the Deque WAS prep course and took thorough notes Areas of the BOK I plan to focus studying on: anything with ARIA, JavaScript, AJAX, and API's more about screen reader interaction model for touch screens spee...

It's hard to talk about a passion that you have without sounding overdramatic or hyperbolic. The path that led me to becoming a user experience professional, for me, felt like a series of revelations and sparks of discovery. I sometimes look back and think about what would have happened had I not been introduced to Photoshop and shown how to code a basic website. That was, without a doubt, the most pivotal event of my life. Since then, I've learned and grown and become passionate about user experience enough to rely on it as a career and outlet for creative energy, and until a few years ago, accessibility was something that wasn't important or interesting enough to spend time on. A client request was made to incorporate screen reader capabilities for JAWS. None of us had much accessibility experience outside of alt text on images, so we took a few weeks and dove completely head first into how to accomplish this. A fire was lit. A door opened. The way I thought abou...