Axe-con ’27: The world’s largest digital accessibility event.
At your computer.
February 23-27, 2027
Me! I’m a keynote speaker along with Jennison Asuncion, Co-Founder of Global Accessibility Awareness Day (GAAD). There will be 70+ other amazing presenters as well I’m sure that will be announced soon.
Because it matters.
Yet again, the industry has been let down by DigitalOcean and their abandonment of CSS-Tricks. It's time to step up and protect publishers whose goal is simply, to educate and share knowledge.
The great folks at Calibre just don't miss. Another great deep-dive.
Nothing sounds good is a great service and they've expanded with this immense resource for finding gigs near you.
BBC News get a lot wrong, including their RSS feeds, so Dan has fixed that part at least.
This is just delightful.
Here's one from the Piccalilli archives that you might have missed to wrap up this issue.
P.S. this is a good website from personalsit.es.
Our huge 35% discount on all courses ends on Tuesday. Use the coupon code PRICEFALL at checkout.
Don’t miss out!
I think I bought this thing at some grocery store endcap or something.
The magic is that it can do all three advocotasks:
Amazing! All in one!
My review: I actually kinda like it. I do reach for it when I have this job.
But I’ve shown it to several people who have almost viscerally bad reactions. Like, they can’t explain it; they are just: nope. I literally handed it to someone who was about to undertake the job of slicing avocado, and they were like no thanks, got my knife here.
The downsides are:
Now that we can better customise <select> elements, it's only natural to side-eye other form <input> types that have caused us visual headaches.
Sure, we should be applying the lightest of touches to form elements, especially, but even with a bit of visual-massaging, checkboxes are limited, aside from a bit of accent-color.
See the Pen Standard checkbox with accent colour by Andy Bell (@piccalilli) on CodePen.
There is a brighter future incoming, if you're to read the spec:
The ::checkmark pseudo-element represents an indicator of whether the item is checked, and is present on checkboxes, radios, and option elements.
Match that with appearance: base, which is also incoming, and we're looking at this sort of CSS:
Logininput[type="checkbox"] {
appearance: base;
}
input[type="checkbox"]::checkmark {
content: url("data:image/svg+xml,%3Csvg aria-hidden='true' focusable='false' width='24' height='24' viewBox='0 0 24 24' xmlns='http://www.w3.org/2000/svg'%3E %3Cpath fill='none' stroke='currentColor' stroke-linecap='round' stroke-linejoin='round' stroke-width='2' d='m5 12l5 5L20 7' /%3E %3C/svg%3E");
}
We're miles off from that capability yet — it doesn't look like any browser is working on it — so allow me to show you how to build a nice custom checkbox pattern for until we have the browser capabilities we're after.
It's always right to start with some good quality markup:
<label for="custom-checkbox" class="checkbox">
<span class="checkbox__box">
<input type="checkbox" name="custom-checkbox" id="custom-checkbox" value="Some value that this control toggles">
<svg aria-hidden="true" focusable="false" width="24" height="24" viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">
<path fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" d="m5 12l5 5L20 7" />
</svg>
</span>
<span>A long label for this checkbox to make sure we get a nice wrapping behaviour</span>
</label>
The markup is pretty straightforward here. Inside the parent <label> — which is linked to the input both by being a parent and the for/id attributes — we have a container for the input and icon, along with a text label.
The reason I'm using <span> elements here is because aside from the input/SVG only phrasing content is permitted. I don't think a <div> would do any harm here, but it's best to do things right.
On the SVG checkmark element, there's an aria-hidden="true" attribute. This stops the SVG — a visual element — getting in the way for assistive technology. I've also added focusable="false". This is actually a relic from the Internet Explorer days hell, but I keep it on visual only icons, just in case.
Right, we're in good shape. Let's make it look good.
The first thing to do is layout:
.checkbox {
display: flex;
align-items: baseline;
gap: 1em;
text-wrap: balance;
}
Flex is more than capable here. I like to align on the baseline in this sort of context because as the viewport gets small and the text wraps, we don't want a vertically centered layout. It looks rubbish!
Speaking of balance, I'm using text-wrap: balance here for the same compressed viewport context and dealing with wrapping text. Keeping a consistent edge (rag) is extra important for small microcopy, such as labels.
Let's tackle the input itself.
.checkbox input {
margin: 0;
width: 100%;
height: 100%;
appearance: none;
position: absolute;
top: 0;
left: 0;
border-radius: 0.2em; /* This is so the focus ring has a matching radius to the visual box */
}
We've got to be really careful here because we don't want to mess up the focusability of our element. Combining appearance: none and absolute positioning, our element is still there, but its no longer in the way, visually. It can still receive focus and will present a focus ring, which is exactly what we need!
Let's tackle the "box" part, which is also this <input>'s parent.
.checkbox__box {
position: relative;
background: transparent;
color: currentcolor;
border: 1px solid;
width: 1.4em;
height: 1.4em;
transform: translateY(0.75ex);
flex-shrink: 0;
border-radius: 0.2em;
}
A lot of this is self explanatory but I'll pick up the key parts:
position: relative so the <input> stays inside this boxtransform rule is a bit of a magic-number but because it's a relative ex
unit, it scales quite nicely, regardless of parent font size. Most importantly the ex enhances that baseline alignment and fixes the initial alignment of the <input>I really like how Ahmad Shadeed approaches this too. That's the beauty of CSS: there's plenty of ways to do things well!
Let's deal with the SVG checkmark next:
.checkbox__box svg {
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
pointer-events: none;
display: none;
width: 1em;
height: 1em;
}
I guess I could use logical properties here, but we're positioning an icon in a box, so the "old" way works perfectly well.
The idea here is to visually hide the checkmark when the checkbox isn't checked and show it when it is. We'll deal with that CSS next.
.checkbox__box:has(input:checked) {
background: white;
}
.checkbox__box input:checked + svg {
display: block;
}
We're in checked state territory here. I'm setting a white background using :has() which is yet another useful use-case for this endlessly handy addition to CSS.
The following block of CSS uses a traditional next sibling selector to show the SVG element when the input is checked. You could use :has() here too, if you're feeling fancy.
With all of that CSS in place, we're looking good.
See the Pen Custom checkbox by Andy Bell (@piccalilli) on CodePen.
There's nothing stopping you using this approach for radio buttons. Check out this demo where I'm using a circle icon instead of a checkmark. It works well!
See the Pen Custom radio buttons by Andy Bell (@piccalilli) on CodePen.
The eagle eyed amongst us will have noticed that aside from the transform rules, I've consistently use em units. The reason for this is so our checkbox can scale with no other intervention.
See the Pen Custom checkbox - massive edition by Andy Bell (@piccalilli) on CodePen.
The only change here, versus the first demo is a font-size declaration on the .checkbox component.
A handy pattern, right?
A big thanks to Jake Archibald and Heydon Pickering for checking my homework.
The commerical airport we use here in Bend, Oregon is actually in Redmond, Oregon.
Flights from here generally depart very early. It think it’s because they need to make it to bigger airports to make connections to further-away places.
Flight typically depart at 4:30-6:30 AM. They want your bags an hour before departure, and the airport is 30 min from Bend, so you gotta be out the door sometimes at 3:00 AM meaning ungodly 2:30 AM alarm clocks.
That’s the extreme case though. If you aren’t checking a bag and you’ve got a 6:00 AM flight, maybe you’re leaving the house at a spicy but tolerable 4:45 AM.
That was too much preamble for this, but now you know.
The one giftshop/coffeeshop in the airport opens at 4:00 AM. One person opens it up and starts selling things to the couple hundred people milling around in the one terminal preboarding area.
This shop sells all the normal stuff you see in airport giftshops like cheezy Central Oregon sweatshirts and magnets, cold beverages and string cheese, magazines, and the like.
They are also, and perhaps mainly, a coffeeshop.
People stand in line to buy coffee. It’s early in the morning. You can’t bring in liquids. It’s damn coffee time.
Right in the heat of the morning airport action, there might be 20-30 people in line. It’s a whole thing.
Now we’ve arrived at my point.
What do you order from this one person working at this coffeeshop at 4:00 AM?
You can’t help but be aware there are 20 people behind you in line and how there is one person taking orders and making the coffee drinks. Right?!
You could order a latte, which will take like 3 minutes to make. Or you could order a drip coffee in which this person hands you a cup in 3 seconds.
My brain is built such that I cannot possibly order something that will take this person a while to make. Like the words would be unable to come out of my mouth. Even if a cortado sounds really good right now, actually, I can’t do it. I can make an active choice to get a perfectly fine drip coffee and get this line moving and get all these strangers-yet-neighbors their coffees too, or I can cause a big ol’ hitch in the giddyup.
I hope I’m not trying to grandstand how perfect I am. I’m showcasing one part of how my brain works. I really don’t like inconvinencing other people.
I notice, because it seems like plenty of other people don’t.
People order cappaccinos and flat whites and all that shit without abandon.
The line takes forever. It just is what it is.
And we come to why I titled this The Rude Trifecta. These mocha-ordering fellow humans must fall into one of these categories:
I actually don’t know how it would break down if there was a way to figure it out, but I suspect it’s a fairly even mixture.
Like for some, it just doesn’t cross their mind that it’s any problem at all to order a 3 minute drink. It’s a coffeeshop and they ordered a coffee. Maybe if they thought about it for far too long like myself, they could see the problem, but that’s not their normal thinking pattern.
For others, they couldn’t give any less fucks. Again it’s a coffeeshop and they ordered a coffee. They stood in line like everyone else. Yeah, it might take a while, but it’s their turn and they are going to use it. Put whip cream on it motherfucker.
The last one is very similar to the above, but it’s more intellectual. Again it’s a coffeeshop and they ordered a coffee. This is not a rude action. It’s not on them to dechiper what is and isn’t rude on a menu, or to personally shoulder a understaffing issue. They might go so far as to think it’s actually rude in the other direction, where self-censoring an order doesn’t give the business the appropriate feedback on their operations.
That’s why if I was with a friend and they did it, I’d be totally fine with it. I can’t do it. I can’t ask them to get me the americano. But their actions are their own and this isn’t a situation where I cast any judgement. I mean assuming it’s #3 and not #2, that is.
Speaking of airports and flying, this is why I literally cannot recline my seat if someone is behind me. It takes up their room. Can’t do it.
Reminds me of a recent-ish Marcel post:
I feel like the neighbor:
Arc is the greatest web browser ever, and has been tragically moved-on-from by The Browser Company of New York-come-Atlassian. I’ve been back on it the last month or so though. It’s still very usable as they keep the Chromium version updated.
I just really like it. It’s so good. My second favorite is Zen because of how well it follows in those Arc footsteps. But I’m attempting a jump over to Dia, the sorta-kinda-Arc-replacement, as it seems like that’s where the effort is focused. But is it?! I don’t see a ton of action on Dia either, to be fair. But they have seemed to bring some of the great some from Arc over to Dia, so I figured it was worth a shot.
There is already a bunch of paper-cutty stuff I don’t like, but I gotta give it some time, so I won’t dig into all that just yet.
Right now I’d just like to explain one thing I think Arc really nailed: Tab Heirarchy.
It’s sort of like a 4-tier system.
These favicon-only buttons are tabs that persist across all spaces. Their position and ubiquity make them, perhaps, the highest tier tabs.
At one point I had it in my head that Arc “kept these tabs hot” meaning if you clicked onto one of them, it was already rendered, so you felt no delay as that page loaded. Not super sure that’s true, but it would be cool if it was (and worked so well it was obvious).
The icons are a little small which reduces their prominence a smidge, but I’d still call them the top.
The Problem in Dia: Dia has these, but there are Profile-specific, which to me ruins the heirarchy. Why have them at all if they don’t have the ubiquity?
I really don’t know what to call these, but they are also high on the hierarchy and probably equal to those pinned tabs in importance. But they don’t persist across spaces — they are very space-specific.
They’re below the pinned tabs, but above (separated by a little line) the regular tabs. These tabs sort of behave like bookmarks, which is a fantastic feature that I’ve really grown to love. You can just close them and instead of literally closing and disappearing from the sidebar, they just reset to their main URL. Closing them is just like resetting them. You can remove them, of course; it’s just a more explicit action. These are great.
The Problem in Dia: None. Dia has these and they are fine.
The tabs below the little line are regular tabs.
They are remarkable for their unremarkableness. They are just tabs. You open them and close them and behave exactly how you’d expect a tab to be.
They do have one notable feature: Arc has a setting to auto-archive these tabs after a set period. It’s like a “save you from yourself” feature. I have mine set to 30 days, as I actually don’t like this feature. I keep a tidy browser anyway and don’t need to be saved here. I know some people really like it though, people that I assume also have Roombas.
The Problem in Dia: Dia just doesn’t sync these?! WTF?! It syncs literally everything else but just stops short of syncing your normal tabs.
Perhaps the lowest on the hierarchy are “Little Arc” windows.
It takes some serious getting-used-to in Arc that you don’t open multiple windows. You just have the one browser window. It’s weird to have multiple windows. It lets you, but it probably shouldn’t.
Instead, if you need a 2nd window for a sec, which is legit, you just open a Little Arc, which is this very transient browser window with none of the Arc UI around it. You do your little thing and close it. Or, you “promote” it to a regular tab with the one prominent button a Little Arc has.
Little Arc is what Arc uses to open links from other apps. Like if you click a link in your email app, it’ll open in a Little Arc first. I love this. Chances are, these are ephemeral browser “tabs” I just need to look at for one sec, then whisk away. If not, I’ll just promote it.
The Problem in Dia: Dia just doesn’t have these ephemeral windows. Booooo. This is the #1 loss I feel in Dia.
Both Arc and Dia have this nice feature where you basically ⌘-T to make a new tab, and type in what you’re looking for. But it doesn’t just do one thing. It’s got a menu of choices. Of course, the top choice needs to be right most of the time, and it usually is, but options are nice.
The Problem in Dia: It’s just not as good as Arc was. For one, it really wants to hijack many would-be web searches for “Chat” instantiations. So it answers with some ambigous LLM instead of searching. I use AI, but I literally never want this in Dia as I’d rather just use an LLM of my choice. Dia also isn’t as good at commands. It change change color scheme, it can’t open browser extensions, it doesn’t have splitting commands, lots of missing stuff.
I mentioned this above briefly, but I’d like to mention again:
Your profiles sync. The pinned tabs in those profiles sync. But not your other tabs. This just sucks. I use multiple computers, I want all my tabs to sync.
The Problem in Dia: Normal tabs don’t sync.
Both Arc and Dia have splitting, meaning you can see two websites side by side, which is so good it gets copied. Friggin love it, use it constantly. This is one of the ways “just having one browsing window” works so well. You probably have a system for this if you’re a non-Arc/Dia user already with windowing apps that help set multiple windows where you want them. I actually like just having it done right within one browser window. It just feels good.
The Problem in Dia: It’s not as good in Dia. You can’t drag two tabs on top of each other to split. The command bar doesn’t have a command for splitting. I set up a key command for it which is OK, and you can still Option-Click which is crutical, so it’s live-with-able, but barely.
“Profiles” in Dia are more like how other browsers do it. When you switch profiles, it’s kinda like you’re in a new isolated browser. If you’re logged into CodePen in one profile and then switch to another, you’re no longer logged in.
I would think some people find this an improvement of Dia over Arc, as Arc didn’t have a profiles feature. If they love it, that’s cool, I just never used profiles and don’t like them. I preferred how spaces were just groupings of tabs in Arc.
The Problem in Dia: Dia only has little dots for the Profiles where Arc has icons/emojis for Spaces. I’m not always on a computer with a touch pad, so I preferred the larger click area in Arc.
It’s worth mentioning because Arc forced this, and Dia just makes it optional. To me, it’s required now. And literally all the major browsers offer this now, which to me proves how rad it is. Dia does side tabs just fine.
There are little things I prefer in Dia, like I didn’t need the Easels and Boosts and all that, so the removal of those things is fine with me.
I pulled the trigger on an underdesk treadmill. Basic research suggested GoPlus is a decent one. I was hoping it would be $300-400 USD. Turns out this one is just $119.99. So cheap it had me a little worried, like it was going to be cheap junk, but I pulled the trigger anyway. It took 2-3 days only to get here, and it’s… kinda nice?
They must be trying to unload them or something cause it seems a little too to be true. Ask me in a few months I guess.
In this post, User Experience team intern Hannah Watson shares her work over the summer researching digital content accessibility with the EdWeb 2 publishing community.
As part of my internship with the User Experience Service, I have been investigating digital accessibility at the content level across University web pages, particularly on EdWeb 2 sites. Digital accessibility at the content level is about applying principles of accessibility to how web content is written and formatted. This includes, but is not limited to, content features such as heading levels, links, and alt text. It does not include anything that is not involved with content design or that is controlled at a higher level by the Content Management System (CMS), such as font, font size, or colour contrast.
The specific research questions for this project were:
More comprehensively, I was investigating the accessibility of:
For more detailed guidance on these topics, please refer to the University of Edinburgh editorial style guide.
Editorial style guide | Information Services
This research has been necessary for the User Experience team as it allows us to identify which areas of content accessibility are challenging for web publishers. From this, the team can adapt guidance and training to provide extra support on these more challenging areas where possible.
I started my research by setting up short, informal interviews with six University web publishers. In these interviews, I asked the publishers about their experiences of creating digitally accessible content. The aim of these conversations was to understand how publishers learned about digital accessibility and what challenges they face when making content as accessible as it can be. During the interviews, we referred to web pages that these publishers work on to get concrete examples that illustrate the topics we discussed. Through these interviews, I was able to identify a number of trends, particularly in the challenges that the interviewees and their colleagues face.
Following these interviews, I created a survey to further investigate the findings and collate more supporting evidence for these findings. The survey consisted of 10 questions, three of which were demographic based as a filter, with a final question asking permission to follow up with those who responded.
The other six questions asked about:
The findings from the survey were effective in making the information gathered in interviews more robust and provided further evidence for some trends that were identified previously.
To publicise this survey, I sent a brief statement explaining my research into two Teams channels, the Web Accessibility Special Interest Group and the EdWeb 2 Community. Overall, the survey received five responses, and while this is a limited number, I found that it helped to support the findings from the interviews.
The final method of research that I used to learn about the digital accessibility of content on University web pages was by looking at pages that were submitted within Effective Digital Content workbooks as part of the course. The course requires learners to choose pages from a University website and assess the effectiveness of the content. By looking at the pages that learners selected, I was able to use active examples and make note of content accessibility issues that were present on live pages. This process also highlighted a number of trends.
This method of research was also useful in that it provided two separate sources of data. Firstly, the answers in the workbook helped me to gauge learners’ understanding of the principles covered in the course. Secondly, the web pages linked by those taking the course allowed me to have live examples of content to assess against content accessibility principles. While there was not necessarily overlap between the answers in the workbook and the pages submitted as part of the workbook (as some people may not have been fully or at all responsible for the content on those pages, or the content could have been updated since the workbook was submitted), it was useful to see these things separately.
Combining findings from all areas of research for this project, I have identified a number of trends in the accessibility of digital content.
In the interviews and the survey, participants were asked what principles of accessible digital content they actively used when designing content. More than half of participants mentioned three principles in particular, with all participants mentioning at least two, which were:
Interestingly, while these principles were mentioned frequently by participants, and evidenced by the websites that we discussed in interviews, they are also principles that are often missed on University web pages. This is discussed in more detail in the corresponding sections further on in this post.
One standout finding from the interviews was that web publishers sometimes struggle to find an effective alternative to PDFs. While PDFs are not necessarily accessible, they do have benefits which make them useful for publishers. For example, they are downloadable, searchable, and cannot be easily edited without permission from the owner. There are ways to make PDFs more accessible, such as avoiding decorative images, adhering to accessible content design principles within the PDF, and checking colour contrast. However, the interviewees were more in favour of finding a way to turn their content into a webpage as this is more likely to result in accessible content.
Out of the survey responses, three also mentioned that they had recently chosen to publish content as a web page rather than as a PDF, highlighting their knowledge that a web page is preferable in terms of accessibility. However, their personal preferences or how difficult they found this is unknown as I was unable to follow up with these participants.
Across web pages that I assessed for correct heading levels, there were several which skipped heading levels throughout the page content, such as going straight to a heading 3 without that heading being nested within a heading 2 section. Additionally, headings on the University web pages that I investigated were often generic, instead of being specific about what a page or section will contain, which is the recommended approach.
The fact that the web publishers who were interviewed and surveyed were aware of the importance of correct headings levels and specific headings, and that the majority of these publishers have attended a staff training or used the editorial style guide, suggests that the guidance provided is accurate and useful for publishers.
To increase the use of correct heading levels, as well as clear and descriptive headings on web pages, participant responses suggest that increasing the reach and engagement of existing training and resources involving headings would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.
In three of the interviews, and in two survey responses, participants mentioned that they struggled to find the time to add alt text to images on their web pages. However, participants in the interviews also stated that they understood the importance of alt text, and what writing meaningful and clear alt text involves. This is reflected in the answers in Effective Digital Content workbooks. The course contains a question asking learners to write meaningful alt text for two images, and this question is often answered well. This suggests that web publishers understand how to write alt text, and that the obstacle in doing so is more likely to be related to time and resource.
One way that time constraints on adding alt text could be improved is to reduce the number of images on a web page, which will not only make this task more manageable but also is also more sustainable.
All five responses to the survey stated that they had explained an acronym or abbreviation recently. Although this did not come up in the interviews often – only once – the survey responses suggest that this is common practice for web publishers who are familiar with digital accessibility principles.
Participants stated that they understand the importance of clear link text as a principle and make effort to implement this into their content. However, similar to headings, this sentiment is not reflected across numerous University web pages. In some of the pages submitted as part of the Effective Digital Content workbooks that I investigated, there were frequent occurrences of inline link text, or link text that does not clearly describe the linked destination.
To increase the writing of link text on a separate line, as well as clear and descriptive link text, participant responses suggest that increasing the reach and engagement of existing training and resources involving links would be effective. This includes training provided by the User Experience Service, such as Effective Digital Content or Content Improvement Club, and the University of Edinburgh editorial style guide.
A trend from both the interviews and survey responses is that for many of the people involved with this research, their knowledge of digital accessibility started with a personal interest. Specific examples of this that participants mentioned include learning about accessibility as a student (and then going on to be an accessibility advocate for a student society) and working with disabled students and learning through experience.
During the interviews, multiple staff members mentioned that they believe, through their experiences, that a large part of issues with creating accessible digital content at the University surrounds communication. A combination of factors was discussed that had communication at the centre, including:
Job-based constraints were also mentioned frequently, such as limited time to add alt text to all images on a web page and working on a page where the lead publisher takes a design forward approach which can sometimes clash with accessible content principles. These answers were also reflected in the survey responses, with all of the responses mentioning either one or both of these problems.
The primary resource that participants mentioned using to learn about digital accessibility and develop their skills was University-provided staff training, with 10 of 11 participants mentioning this. Effective Digital Content was specifically mentioned twice, and Content Improvement Club three times. In the interviews, two participants mentioned more general staff training, with one survey response saying the same. In the survey responses, three participants also said that they used training provided by the Disability Information Team.
The Web Content Accessibility Guidelines 2.2 (WCAG) is another resource that was frequently mentioned by participants, with six in total saying that this is a resource that they use as guidance on accessibility.
The University of Edinburgh editorial style guide was mentioned by five participants as a resource that they used to provide guidance on digital accessibility, in which the guidance reflects what publishers learn in training courses, meaning that information they take from the style guide is in line with accessibility and content design training.
I learned a lot during my time researching how web publishers at the University of Edinburgh approach creating accessible digital content. I thoroughly enjoyed the opportunity to work with staff from a variety of different areas of the University. This helped me to learn how to identify commonalities in interview and survey responses despite the areas of work being distinct. I also enjoyed this because I was able to learn much more about the work that goes on across the University and what the work of other teams involved.
I also particularly enjoyed the format of my internship being a combination of individual work and working with other members of my team and the Disability Information team. This balance allowed me to set my own goals while still getting the opportunity to work and learn collaboratively as part of a team, prioritising my tasks between my own and those that I was working on with others.
A limitation of my work was that it was much easier to contact and work with staff who have a genuine interest in the subject area of accessibility, which does not lead to research that is representative of how University staff approach digital accessibility as a whole. Having done the research that I have so far, a continuation of the research would be most beneficial if it focused on the experiences and approaches of staff who are less familiar with digital accessibility requirements and principles, as this would create a more well-rounded understanding of web publisher accessibility approaches at the content level.
Furthermore, another limitation of the work was the time constraints which have restricted my ability to develop solutions to issues identified during the research period. This was expected to a degree, as the solutions depended on the outcomes of the research, which has taken the majority of the 12-week period. The positive outcome of this is that the research and findings will provide the User Experience service with information that allows for both further research and for adaptations to guidance and training if it is deemed necessary.
This research has helped the User Experience Service to assess their training and the resources that are available for publishers to learn more about digital content accessibility. Keeping in touch with the publishing community through projects like this helps the team to direct their effort to real challenges that publishers face on a day to day basis.
The research completed throughout the duration of this project will be supported and advanced by further investigation, particularly by communicating with web publishers who are less involved with digital accessibility as a whole. This will likely help in providing more concrete solutions to digital content accessibility issues across EdWeb 2 pages.
I’m Grace, the Web Registry Development Intern for the 2026 Summer! As my internship draws to a close, I discuss how my AI Supported Accessibility Testing, and my Web Estate Dashboard projects have progressed. The first project focused on investigating how AI can be used to automate accessibility testing websites. My second project aimed to produce a dashboard for non-technical audience so they could see their website statistics. I reflect on my project, my experience, and what I’ve learned.
Almost three months after I started, my internship is wrapping up. My Summer project aimed to investigate how AI can be used to automate accessibility testing, so we can make sure the web estate is in compliance with Web Content Accessibility Guidelines. Currently, most automated testing (programs like axe DevTools) catches approximately 30% of errors, I aimed to increase that accuracy and investigate where AI can be useful. I’ve learned a lot, but there’s still lots more for me to pick up! The goal was to get AI to test for WCAG violations more accurately, and see if it could be a useful tool in the testing process.
Rather mundanely, AI won’t be taking over the world anytime soon. AI supported accessibility testing still hovers around 30% accuracy.
The agent is good at crawling through sites and identifying suspicious elements that commonly produce issues, things like a pop-up widget or a pdf. It also excels at anything related to markup languages, testing guideline 1.3.5, identify input purpose, for example, which looks to see if input fields are labelled correctly, so computers can autocomplete them. These black-and-white guidelines are easily digestible for AI, it’s when a human aspect in included that AI can stumble.
In conversations with the accessibility team, it was noted that AI struggles with the “grey-areas” that pop up in the testing process. While the full list of WCAG guidelines is lengthy and specific, the primary goal is to make sites usable for all. A guideline may not explicitly outline why a website fails, but if a human finds it inaccessible, that means it’s inaccessible! An element’s context within a website can drastically change whether or not it’s WCAG compliant, this was something that agents struggled with. I found that agents are too scared to get something wrong to think critically or apply executive judgement.
Aside from that, guidelines that measure things like a logical tab sequence—measuring how intuitive it is for someone to navigate a website with a keyboard—should continue to be tested and reviewed by humans.
In the beginning, I did some desk research to find the AI agent best suited for the task at hand. I investigated the different LLMs available through ELM, with varying success. They could analyse whatever screenshots I gave them, but that still required me going through a website and selecting information that was relevant. I pivoted to the ChatGPT software, which was then called Codex. Codex could exit its window and crawl through the site itself autonomously, more closely mimicking how accessibility testing is actually carried out. It was a bit of a learning curve, lots of failed audits that I got to learn from. Throughout the summer, I iterated a master prompt to feed to agents, tinkering away at it bit-by-bit. I made it modular, so it was easy to swap out guidelines based on what you wanted to test. Currently, the prompt sits at 7252 words, and each guideline is split into smaller sections.
The AI specifications section contributed the most to the wordcount. You have to be very specific about the exact path you want the agent to take. It’s good that you get to have specific control over the testing, less great when you have to soft-parent an agent through pressing the “Tab” key.
This prompt would then produce an audit report, this is distinct from a completed accessibility report. The audit was produced to help a tester identify issues, not to present findings to a wider audience. During my internship, I gave weekly updates to the accessibility team and I was consistently given really valuable feedback that I could integrate back into the master prompt. At the end of my internship, I started scoring the accuracy of the prompt against preexisting human accessibility reports.
The aim of this project was to pull data from a registry service using its API capabilities and present it in a user-friendly dashboard. I wanted to make sure the entire process was cheap, secure, and easy to upkeep, qualities that can be tricky to balance all at once.
I split the project up into 2 phases. Phase 1 covered transferring the data from the registry to a PowerBI dashboard, which was a bit of trail and error, but was successful. Phase 2 covered adding specific filtered to the dashboard depending on the user, and these filters would be added autonomously, without requiring users to manually log in every time. Phase 2 was a lot trickier, and s still incomplete.
This really tested, and expanded upon, my technical skills. Through my astrophysics degree, I do a lot of data analysis and presentation through Python. However, the data in a university setting is reliable, easy to obtain, and consistent, this isn’t the case with this project! It was really interesting working with data that has real-world implications and it changed the way I think about my data analysis. I used Python code to make my API calls—the thing that gives me the data from the registry—which confused me at first, but everyone on my team was happy to answer all my questions. I was able to pull the data from the registry and produce a PowerBI dashboard that presents all this data simply.
Applying the filters to the dashboard is relatively straightforward. Phase 2’s main difficulty is accessing employees’ names and departments, data which is quite sensitive and requires high admin permissions to access. Naturally, any workflows would have to ensure employee data is handled securely. In order to produce a successful dashboard, the current web registry data would need to be completely reorganised. To create a robust dashboard, the data—including employee data, stored separately—would also need to be accurate.
I’m still a long way from understanding the ins-and-outs of accessibility testing, but this project certainly built up my confidence in the subject. It encouraged me to think about the logic of these guidelines in creative ways, to make it better digestible for AI. After all, how would I train an AI to test a guideline if I myself didn’t understand it? While the project didn’t produce earth-shattering findings, the findings are still inconclusive. We should continue to explore tools to make websites more accessible, especially as AI continues to evolve.
The dashboard helped my technical skills grow, and taught me to come at an issue from many different angles as certain avenues were rejected. The dashboard project taught me that there sometimes isn’t a “right” way to do things and that sometimes you have to juggle conflicting considerations in a project.
Overall, I’m really grateful I got to evolve in this way and I’m excited to see what future projects can accomplish!
I’m a good 50/50 split on music and podcasts while I’m driving. So lots of podcasts! I love them! I use Overcast, and it’s got a decent CarPlay app. So I see this screen a lot:
It shows 3 podcasts I’ve started and 5 of the most recently published podcasts to choose from.
THIS IS THE SCREEN.
I want to be able to go: I’m done with this podcast episode!
It’s pretty common that I listen to half an episode or so and I feel like I get it, or it just isn’t for me this time. I want to whisk it away! I’m done! Replace it with something else, please.
In Overcast, it’s likely I have 10+ podcasts I’ve started, so when I remove one of the top ones, it could just be replaced by another. But that doesn’t even matter; that area could be cleared out.
I just don’t listen to every episode of every podcast. My drive time doesn’t allow for that. So I try to monitor my attention and engagement, and if a podcast isn’t grabbing me, I shoo it away and move on to the next.
The trouble is, there is no mechanism for this in the Overcast CarPlay app at all. The only thing is either getting out my phone to swipe away the ones I’m done with, or playing the podcast and 30-sec-skipping my way to the end so it’s marked as finished.
A swipe gesture to archive, or just an archive button, would be great.
