The Authoring Tool Accessibility Guidelines (ATAG) are guidelines for tools that create web content. While reviewing this week, I wondered if the Text Search criterion (A.3.5.1) is met as soon as users can use browser built-in search. You know,
Ctrl/⌘ + F. Turns out: yes, if the tool is browser-based and the UI contains all the necessary content in a way that CTRL+F can find it.
Let's look into a bit more detail. The criterion requires that text content in editing views can be searched:
A.3.5.1 Text Search: If the authoring tool provides an editing-view of text-based content, then the editing-view enables text search, such that all of the following are true: (Level AA)
(a) All Editable Text: Any text content that is editable by the editing-view is searchable (including alternative content); and
(b) Match: Matching results can be presented to authors and given focus; and
(c) No Match: Authors are informed when no results are found; and
(d) Two-way: The search can be made forwards or backwards.
(From: ATAG 2.0)
True accessibility depends on a combination of factors: browsers, authoring tools, web developers and users—they can all affect how accessible something is. ATAG is about authoring tools specifically, so my initial thinking was that for an authoring tool to meet this criterion, it would need to build in a text search functionality.
However, reading the clauses, it sounded a lot like what
Ctrl + F/
Cmd + F in browsers already facilitate. Great news for authoring tools that are browser-based (sorry for those that are not). Browser built-in search finds all visible text in a page (as well invisible text in details/summary browsers), matching results are presented, “no match” is indicated and search works two ways. It doesn't find alternative text of rendered images, but if you have text input for alternative text, it finds the contents of that.
In Chromium, when the “hidden” part of a
summary contains the word you search for, it goes to open state (this is per spec, but Firefox and Safari don't do this yet)
Note: in screenreaders, the experience of in page search is not ideal. I have not tested extensively and am not a screenreader user myself, but quick tests in VoiceOver + Safari and VoiceOver + Firefox indicated to me that one can't trivially move focus to a result that is found and “no match” is not announced, it needs cursor movement to find. This seems not ideal, but again, I am not a screenreader user and may be missing something.
All in all, the in-browser seems to satisfy the requirements. Lack of matches is indicated (though not announced) and matches can be given focus (though the browser doesn't do it; not sure how that would work either as the matches will most likely not be focusable elements so that would be a bit hacky and it would not solely have advantages). These caveats are accessibility issues. I feel they'd be best addressed in browser code, not individual websites/apps, so that the solution is consistent.
Ok, so if the browser built-in search meets the criteria, let's return to the question I started with: should an authoring tool merely make sure it works with built-in search, or should it implement its own in-page search?
The unanimous answer I got from various experts: yes, in this case the browser built-in is sufficient to meet the criterion. It also seems reasonably user friendly and likely better than some tool-specific in-page search (but note the caveats in this post, especially that all alternative text would need to be there as visible text). Of course, most authoring tools have more search tools available, e.g. to let users search across all the content they can author. In today's world, they seem like an essential way to complement in-page search, especially as a lot of authoring tools aren't really page-based anymore.
Many thanks to Sara, Jutta, Chaals, Michael and Eric for pointers, help and answers regarding various parts of this post.
Comments, likes & shares (5)
and Ash liked this
Curtis Wilcox reposted this
Bit of a pancake week. Felt like I was stretched too thin across things to add any value, but wrapped up the week with positive chats and thoughts. Bit of a 180. Glad I’m not the only one.
And as I started writing these, another 180: realised I hadn’t transferred 2FA codes over to my new phone before erasing the old one. My opening salvo at sunrise was ‘FFS’. But a quick restore from an iCloud backup meant I could recover the codes and move them to a new device. Phew.
What other miniature misfortunes may befall me? Who cares, it’s all good in the end.
So, what value did I squeeze out of the Stone of Potential this week?
Since Microsoft announced that Internet Explorer 11 will go out of support, the GOV.UK Frontend squad has been thinking about how we’ll reduce support for IE 8, 9, 10 and 11. The use of those browsers has been declining for some time, but some journeys use those and other older browsers. For example, there’s a few transactions a year that take place on a Nintendo 3DS.
What’s tricky is that pressing ahead and dropping support impacts users on older unsupported tech, which goes against our principle of ‘This is for everyone’. But it also means shipping a bunch of code that can negatively impact a user. It’s a heck of a trade-off.
Ways forward were discussed in the morning, but conflicting opinions were halting progress. This is normal in technical teams staffed by experts, your job as PM is to unpack the different opinions and find a collective way forward. But I missed a portion of the meeting to take notes at the town hall, which meant I couldn’t follow the conversation as much. Things felt a little tense at lunch.
On the way back to the office, I laid down a plan: we’ll vote on which questions and unknowns were most important to talk about, and we’ll focus all conversation around deciding on actions we can take to learn more. There wasn’t a shared understanding on the team, one person knew more than the others from having their head in the problem for so long, and that needed meting out to the others. Doing some light discovery work helps teams share knowledge, hence the focus on next steps.
By the end of the day, the team had 3 concrete steps to take next. A success! We don’t have an answer yet, but we have progress. And progress is better than perfection.
When your team is great, you no longer need to worry about user stories and similar granular collaboration devices. Instead you think more about the conversations, the goals of the collaboration, and the environment it happens in. Less about the campfire, more about the camp.
Our accessibility lead showed me their assessment of the work we’d need to do in order to make the design system compliant with WCAG 2.2, part of our accessibility strategy. Thankfully it’s not as much work as we were expecting, but there’s still plenty to do.
We’ll need to do more research or technical investigations to decide what to do about a third of the impacted components, patterns and styles, but the rest shouldn’t need more than changes to guidance.
The benefit of us doing this work is that service teams using the design system won’t have to repeat it, but there is an opportunity to share our thinking. It’s an early idea currently but I’d like to build a tool to help service teams assess the impact of WCAG 2.2 on their service, which should help with planning accessibility audits and changes to their service. I’ll prototype something and share it around, see what people think.
Design system team sizes and maturity
Similar to last week, my chat with a design system manager taught me that government gets great value for money from the GOV.UK Design System. Another team in the private sector is the same size, supporting a smaller number of teams – but they’re comparable in the number of end-user experiences they impact.
A highlight of the conversation was about selling value to senior leadership, which made me realise that we have opportunities for selling the value of the design system through case studies. We have a fantastic story from the pandemic, where we were able to design and build services lightning fast thanks to the design system, reliable platforms and cloud infrastructure. I’ll find out if it’s been written up already, but it’s worth sharing.
I loved, loved, loved the hill session on Thursday morning. The cat woke me up at 5.30 a.m., which he’d been doing all week, the little shit, but I dragged myself out of bed to go run up a hill. It’s a weird part of any running training programme, you exhaust yourself but do see noticeable gains.
A nearby hill that other runners use is called Cypress Road, hence the heading. I ran up the hill as fast as I could for 90 seconds, with breaks in between to jog back down, and did that 4 times. After a 2-minute break, I did 45 seconds running hard uphill with another job break back down, which I did 6 times.
Knackering but with a huge sense of achievement to start your day. Felt so good.
Cooking for others
We had friends over for early dinner on Sunday, to celebrate my partner’s birthday. I cooked a big spread: roasted tomatoes with yoghurt, cannellini bean & fennel mash, cavolo nero & sautéed onion with an anchovy dressing, roasted celeriac with mushrooms, a salumi board, and a big loaf of sourdough.
It’s the second time we’ve had people over in nearly a year of being here, and I really want to do more of that. Had tons of fun in the kitchen, cooking away and chatting. And there’s nothing like seeing all your mates tuck in and enjoy the food. Properly fills me full of happiness.