Cognitive Design Considerations

My current focus has been in the second Deque prep course module on Rethinking Affordances. 

It's been stated several times so far, and in other readings/podcasts, about the design considerations and inclusion of cognitive disabilities is the least common portion of accessibility to be incorporated into electronic information.

This is mainly due to how subjective the criteria are for success in creating accessible content for cognitive disabilities/impairments. I think additionally, this is one of the hardest perspectives to step into artificially, and experience accurately. 

One example designing for cognitive considerations is to make font and language easier to read, and use visual cues to help users focus on action items on the page. How do you define the degree of ease? How do you try to make that consistent and applicable to varying types of information? How do you measure the level of focus they have on any given screen?

Particularly, the guidance stating that you should minimize cognitive skills required to use the page not only is almost impossible to measure accurately, but brings up the questions:

"Is this a requirement for experiences that require a certain level of cognitive skill to use the software?"

"Would it be a better experience if there was a dedicated app to help with specific interactions like memory retention or focus that could integrate with accessible code easier than trying to fit a complex feature into an overly simplified format?"

I don't think it would be a good idea to simplify and minimize certain experiences and functionality just to meet the success criteria for this in particular if it risks causing more issues than it fixes. Ensuring that your line height is the correct measurement, the font style is one that is a certain level of readability, that the language you use is more human readable and concise, and utilizing blank space as much as possible are all relatively easy ways to conform to these criteria. 

However, if more complicated software tried to minimize and simplify, how much of the functionality would remain? Ordering groceries online versus processing payroll should probably not be held to the same cognitive success criteria... to a point.

This is something I'd like to look into in more detail.

There's a W3C task force assembled to dive deeper into cognitive disability as well as mobile and touch device guidelines. ( Cognitive disabilities: Cognitive Accessibility Roadmap and Gap Analysis) The gap analysis is a work in progress, but I'm so glad that it's available to the public to see it evolve as they work on it. I'm anticipating that their findings and conclusions will be integrated into the future release of WCAG 3.0, but I've not found confirmation on that.

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