Accessibility advocates and pizza toppings
, by Detlev Fischer
Accessibility advocates can be quick to rubbish articles from people from a design / user experience field. Sometimes it is worth taking a second look.
In some recent twitter interactions around pieces like the "Aesthetic-Accessibility paradox" (look it up if you like), I noted that many in the accessibility community get upset when people from a design / user experience background choose to pick a fight about accessibility issues. But why is an irritating article called 'not worth reading' or not deserving 'link juice'? Why do people advise others in the accessibility community (if that exists) 'Do not read that, read something else instead'? (Besides, advice not to read something is bound to have the opposite effect.)
I fear that anger about admittedly dubious, misinformed, cavalier and ableist positions makes people roundly dismiss design aspects that are worthwhile thinking about, simply because they are brought forward by someone they dislike. (If it is true that the author indeed deletes and even edits replies to his articles as Adrian Roselli claims, this would be the end for me – I'd stop engagement).
One line of attack in the comments: Articles should not recommend design solutions if these are not backed up by user testing or other research. The fact that design recommendations are unfounded ("Just do this") will or should make any judicious designer cautious. On the other hand, I do not want to live in a world where people get attacked for floating untested ideas, whether it is out of a personal whim or out of some expectation that what they propose may augment the design repertoire and be useful for designers / implementers.
We have to turn to an example now, and at the risk of being accused of channeling attention and link juice to someone who has received strong criticism in the accessibility community, I will look at the article Why Toggle Tokens Are a Better Alternative to Checkboxes. I find it worthwhile unpicking some of the arguments around the proposed design – in the article itself and in the mostly negative comments.
The checkboxes vs. group-of-buttons case
If you don’t want to read the article itself, the main point can be easily summarized: The author compares two alternative ways of presenting pizza toppings for users to select. He favours what he calls ‘toggle tokens’ – a condensed group of buttons – over a longer list of checkbox options. I am going to look at the different arguments that have been raised for and against the proposed design to see how they stack up.
Scanning vs. recognition
Some comments have maintained that "it is easier to scan a list of checkboxes than a non-aligned group of buttons". It is important to note that what works best in the process of perceiving a list of options is linked to the type of set shown. In lists where you look for one particular element (say, your age or income bracket) a numerically or alphabetically ordered set works well. The situation is less clear-cut for scenarios like selecting pizza toppings. The point is that it is not so much a case of linear scanning but one of recognition – the toppings that you want on your pizza ‘jump out’. I think the assumption that the checkbox list makes selection easier would as much need to be proven in testing as the opposite assumption.
Screen real estate, ‘above the fold’
I think that the screen real estate aspect (all things "above the fold") is indeed a clear benefit of the group-of-buttons implementation and borne out by user research - if there is a way to present all options on the default screen view without users having to scroll down, this makes use easier (including for people with cognitive impairments). It is one interaction less and it works better for those who may not realise that they need to scroll down. Also, native apps often apply a design approach where everything has to fit on the screen, so in these cases, scrolling would not be an option (for longish lists).
The argument has been made in the comments that the list of checkboxes may also be presented in two columns, negating the screen real estate advantage of the group-of-buttons implementation. The trade-off on small screens might be that either some toppings labels may wrap onto a second line or that text would have to be quite small for checkbox/label pairs to fit into 160px (half of 320px) screen width. Which implementation would fare better with sighted users would need to be established in user testing with different layout options.
The semantic argument
Commenters have advanced the argument that what is semantically a list of checkbox options should also be presented as a list (checkbox group). One advantage of that would be that the number of available options is exposed to non-visual users on entering the group.
Other commenters have rightly pointed out that the group of buttons can semantically be made a group of checkboxes, meaning that for non-visual users, there need not be a difference between both types of implementation. What remains is the argument for visual users that expectation is informed by the commonality of / familiarity with other implementations. People know checkbox lists from other sites, so the semantics are clear and appropriate for the toppings selection. But it would need empirical testing with users to establish whether picking toppings from a group of buttons is indeed inferior to picking checkboxes.
A linear checkbox list would have the advantage of being able to reflect alphabetic order and thereby allow predictions as to the position of toppings in the list. However, choosing alphabetical ordering would lead to less common options (anchovies, artichokes) being on top and some very common ones (tomatoes) being way down the list – so it is likely that the order designers will favour would in any case be more like a weighted list based on the frequency of a topping being picked. Which means that the prediction advantage of an alphabetical list would be gone.
Selection communicated only by color
This is clearly a misunderstanding of WCAG Success Criterion 1.4.1 Color – in the group-of-buttons implementation, the difference between selected / unselected is clearly marked not just by colour, but by contrast inversion (dark text on light vs. light text on dark background, regardless of colour). This has also been noted in the comments. The remaining sticking point is that it is visually not clear which state of button is selected and which isn’t. This is technically true, but in any actual use, the user is going to start with a default where all (or most?) options are not selected. Also, the task of selection itself informs the state – I know that I am going to want tomato, cheese, mushrooms and select these, so the course of interaction means that there can be little doubt as to what is the selected set and what isn’t.
Touch target size
Commenters have fielded the argument that implemented correctly, the touch target size of checkboxes need not be smaller than those of the buttons because the labels, when programmatically linked to the checkbox inputs, also respond to the pointer. This is technically true, but my experience in user testing tells me that a considerable number of users are not aware of that and try to activate the small checkbox regardless. In most checkbox implementations out there, there is no visual affordance in the styling of labels that says "hit me", so users will often not perceive labels as active interface components. This is clearly different for buttons, so I think in terms of touch target size affordances, there is an advantage in the group-of-buttons implementation.
This aspect has not been mentioned in the article or in comments. Toppings being grouped close together (in a way mimicking the close position they will later have on the pizza once delivered) may allow for an easier assessment how all the toppings selected so far will work together. If eating a pizza is a synaesthetic experience (the toppings meeting mashed and turned over on your tongue) the group of buttons with options presented in close proximity may afford a better imagination of the resulting taste than the checkbox list where toppings are more spread out. Of cause this is conjecture, but I don’t think an outlandish one.
I think that the case for and against the group-of-buttons design proposal is not as clear-cut as some commenters want (you) to believe, if you ensure that non-visual semantics are on a par with visual semantics. It is actually a good design exercise, and I’d be curious to see results of tests with real users. I understand and mostly share the frustration of commenters. But I think it can be productive for accessibility advocates to be challenged and engage with alternative implementations without dismissing them too quickly. It is more productive to think about how a range of implementations can be made more accessible instead of insisting on one right path. For me, this article and others has been worth reading at the very least for the many comments that have shed light on their misconceptions.