Developer versus user: CSUN 2017

For our CSUN session this year, Léonie Watson and I had a friendly debate about accessibility from the perspective of an end user and a developer.

While we are both accessibility consultants, we sometimes approach issues (and their proposed solutions) from different perspectives due to our own backgrounds. Léonie is a screen reader user in her daily life, which means accessibility problems can personally affect her. I also do development work besides consulting, and strive to make accessibility feasible and pleasant for developers. Finally, Léonie is an active member in the standards community so views issues from a standards perspective, whereas I use standards in my day-to-day work.

Since we’ve found ourselves hotly debating accessibility issues in the past, we thought it would be fun to have an open debate with our ‘user’ and ‘developer’ hats on. To this purpose, three topics were chosen:

• aria-controls
• skipping mechanisms
• link context

At the end of each topic we let the audience vote on who they agreed with most.

Topic 1: aria-controls

I started by quoting Heydon Pickering’s ‘aria-controls is poop‘ article agreeing with it wholeheartedly. I argued  browsers and screen readers currently barely provide any useful functionality for the semantic relationship created by the aria-controls attribute.

Léonie argued that screen readers which support aria-controls provide all the functionality the user needs: a mechanism to skip from a controlling element to its corresponding controlled element. She also showed a video of her screen reader performing this function.

I suggested that browsers should allow screen reader users to do a lot more with aria-controls, e.g. skipping in both directions between controlled elements. I also suggested that these features should be built in to the browser so that keyboard users can benefit from them as well.

Winner: Léonie / User

Topic 2: Skipping mechanisms

We debated whether browsers should by default provide keyboard accessible skipping mechanisms for headings and landmarks. I argued that we should get rid of skip links altogether and suggested it is the browser’s responsibility – provided the developer has marked up their page with a correct heading and landmark structure of course.

Léonie felt that browsers should not be forced to provide this functionality and that HTML itself provides sufficient skipping mechanisms that developers can implement.

Winner: Hans / Developer

Topic 3: Link context

In this last topic, we talked about whether it should ever be acceptable for a link to be context dependent on content outside the link. I suggested that the current WCAG 2.0 success criteria on this topic (success criteria 2.4.4 and 2.4.9) are not always ‘getting the job done’.

2.4.4 allows a link’s meaning to depend on its ‘programmatically determinable context’ (e.g. a parent paragraph, list, or table header), but screen readers and magnifiers do not use this context in any way.

2.4.9 insists that links are fully self descriptive without depending on any outside context. Sometimes this can only be achieved through overly lengthy and verbose link text that is stuffed with a lot of redundant information. Léonie argued that all that’s needed here is common sense and good design.

Finally, I proposed a new aria attribute called ‘aria-contextprovidedby’ which could help assistive technology determine when to read the link in context and when it should be read out of context.

Winner: Hans / Developer

Despite the session being held at 8AM, we had a good crowd that enjoyed the discussion and often chimed in with their opinions.