The Operable Principle - Scenario Exercise

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 fill out the survey. On the home page of the site, the main nav is easy to understand and I can find the COVID survey link (2.4.4) as the first item in the main content region after selecting the "Skip To" link hidden in the header. (2.4.1) There's also the same link available in a menu structure using aria-label "Take the COVID Survey, but the "Skip To" link is faster. (2.4.5, 2.4.9)

The COVID Survey page is correctly titled, and I'm able to follow the DOM order to tab through content in a way that makes sense and see where I am with the clear focus states on each element. (2.4.2, 2.4.3, 2.4.6, 2.4.7)

I'm able to use TAB and SHIFT +TAB to go back and forth between the fields, typing in the values, and hit submit. Something went wrong, and I now have a  pop-up saying I need to make a correction on the form. (2.1.1) I should be already focused on the button that lets me confirm I've read the message, so I can go back to the survey. I shouldn't still be on the page behind the pop-up or required to tab all the way through the page content to get to the pop-up button to dismiss it. I should ONLY be able to navigate within the pop-up until it's dismissed and then returned to my previous focus state on the page behind it. (2.1.2)

If I were filling this out on my phone, having a virtual keyboard appear on the screen does not count as a true keyboard, and I'd have to have a Bluetooth keyboard connected to navigate in place of the touch screen. (2.1.3)

One of the questions in the survey allows for keyboard shortcuts when selecting one of the radio button values from A - D in a list, but I'm only able to use those shortcuts when focused on the radio button group. (2.1.4)

There is a session time-out on the page, and I'm prompted to refresh my session if the remaining time reaches 2 minutes before the page refreshes and I'm logged out. (2.2.1, 2.2.5, 2.2.6) There's a large bright colored banner at the top of the page with information on COVID-related statistics to keep in mind while filling out the survey, and it does not blink because the people who built the site are not monsters. (2.3) If it did, I'd be able to stop it by selecting the "X" on the banner to dismiss it. (2.2.2)

This is a relatively short survey, so I'm usually able to complete it within 5 minutes depending on distractions or technical difficulties that may be unexpected. (2.2.3) 

When I TAB to the "complete" button of the survey (which has a matching accessible name of "Complete" (2.5.3)) and hit enter on the keyboard, I'm brought to the Survey Results page that lets me know if I should take precaution and call my doctor based on the risk factors I entered, or if I'm ok to be socially distancing from my coworkers. (2.4.8)

If I'm found to be at risk, the page displays a map of local clinics that are within a 5-mile radius for me to call. I could use my fingers to zoom into the map if I were on my phone, but they provide a control that I can TAB to zoom in and out, as well as view in north, south, east, and west. (2.5.1)

If I were filling this out on my phone:

  • If I were viewing the map on my phone, I'm able to use my finger to scroll through the map, I want to be sure that my action of placing my finger on the screen and swiping up doesn't perform an action without confirmation. If I accidentally press on a clinic to call, I'm first prompted to confirm that I want to call them after the down event. (2.5.2)
  • When filling out the form, there's an option to undo my last action by shaking my phone, and I'm able to turn this feature on or off if I want. (2.5.4)
  • All the fields and buttons were easy to interact with because their target size was at least 44 x 44 (2.5.5)
  • I have the same seamless experience regardless of browser or device because it's all based on basic HTML and responsive in nature so I'm not forced to only use one mechanism. (2.5.6)


Popular posts from this blog

Practice Site: Keyboard Accessible Tooltip Fail

Image
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 ...
Read more

Pointer Cancellation: Real-World Examples

Image
 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...
Read more

Practice Site: Accessible Forms

Image
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 ...
Read more