User Study
My user is a 21 year old female who has an average understanding of computers and authoring, but is by no means a power user or “techie.” She is studying nursing with a slight background in psychology. I will call her Alice throughout this report.
​
Her first look at the a11yfirst editor was one of slight surprise, which I will attribute to its bare-bones aesthetic and deviation from typical online WYSIWYG editors. She however got the hang of it fairly quick and began running through the tasks, which are listed below.
She managed to author up her content pretty quick, writing out a few lines for titles and typing up a quick paragraph for the body of the post. She questioned me quite a bit about the layout of the site and what exactly the tasks were asking her to do. I clarified without giving away exactly what to click. This was already a red flag, as our tasks were constructed to use the wording given in this particular instance of CK Editor. Further, Alice had some trouble locating exactly which buttons did what, namely the difference between the insert link and insert picture buttons. I think this might be due to her relative lack of experience with online editors like CKE, and perhaps there could be better labeling of the buttons, but I’m reticent to suggest that that the moment.
​
Alice did manage to do quite a few things well:
-
When it was time to add alt text, she reasonably well understood the explanation and the importance.
-
She utilized the quick fixes in the checker with great acumen.
-
She found the checker pretty quick after realizing she could hover over each icon to see a short description.
​
My list of clear faults follows below:
-
It wasn’t clear to Alice that headers were the main way to format this content.
-
She couldn’t figure out why the tab key wouldn’t work with this editor.
-
Note: This is due to the fact that the editor is set up to use the tab key to move focus.
-
-
She scanned very quickly over the various icons (like the insert icons) and needed a second and third glance to find what it was that she needed to complete the task.
-
She quickly clicked through the green “Quick Fix” buttons. This goes against part of our goals, as we aim to increase awareness of accessible authoring. If we were to really do that, it may deserve some redesign to make it not as tempting to click through.
​
I found the majority of these surprising, as for the most part, the editor is set up with consistent labeling. To that end, I’ll chalk that up to lack of experience, as I mentioned earlier. There were no major consistency violations, as she didn’t notice the lack of visual styling until I mentioned it after the conclusion of our test.
Though the list of faults is fairly small, for the purpose of our editor these are major problems. I might suggest the following for remediation:
-
A quick intro to how the editor works (tab key, for instance) above the editor or in a sidebar. This could work in conjunction with the accessibility checker to keep a consistent place for information and assistance.
-
The above would help address a problem that came up when Alice was working through quick fixes. She expected it to stay up, particularly when she was editing the alt text as she needed to make a second change. She couldn’t find out how to make further changes after the checker validated the alt text.
-
A chief complaint was that, although the checker did its job, she quickly clicked through the quick fixes and allowed it to correct her mistakes. She didn’t quite understand the importance of headers and other such accessibility features. She said she would have benefited from easier to digest explanations. Perhaps that is another piece of information that could be contained in a sort of sidebar while authoring a specific part of the post.
​
An example of what this sidebar might look like will be attached to this report (at a later time when I have access to more than an iPad). The sidebar in question is that of the US Government’s FAFSA page, which follows the user through the process offering help where applicable.
My scrawled notes follow below, but this report encapsulates what seem to be some major issues with our editor. Again, while they’re rather minor in the grand scheme of things, when building CKE for a11y first, these are giant problems standing in the way. If we can sort these problems out, I believe that we’ll see a much higher rate of success in immediate understanding of accessibility and its importance in content authoring. I am fortunate that Alice experienced no frustration, as that has been reported by other testers. But I could certainly tell from this test that there is still work to be done even though many of the issues that caused that frustration have been dealt with in previous iterations.
​
Notes
Didn't use heading tools
Bolded the title, italicized the subtitle. Wanted to indent the subtitle
Found link insert, but not photo
Found the checker after looking at options. Found importance of head due to quick help
Plainer terms
Quick fixes help
Found image insert second time around
Mulled over apt text, seemed to understand importance
Expected help box to stay up, confused when it didn't stay