What Is an Agent Harness?

Finding a clear-cut definition of an “agent harness” isn’t easy. This is largely because many AI companies are reluctant to give away the exact approach of how their agents work, often disguising the technical definition in marketing jargon that sounds cool or magical (definitions e.g.: Google, OpenAi, Anthropic).

The best difinition I could find was one I stumbled over reading a Github repo about “Best of Agent Harnesses and Harness Techniques” which quoted a Blog entry from Simon Willison’s Weblog: “An LLM agent runs tools in a loop to achieve a goal.” (6)

Technically speaking, an agent harness is the infrastructure and control layer built around a Large Language Model (LLM). A base model (like Claude 3.7 or GPT-4o) cannot natively search your local files, execute terminal commands, or iteratively fix code—it only generates text. The harness is what grants the LLM autonomy. It provides the model with tools, enforces permissions, manages state, and orchestrates the overarching loop of an agentic session. (1)

Inside Claude Code: Architecture Overview

When we examine the architecture of a sophisticated harness like Claude Code, it reveals a highly structured system that goes far beyond a simple chat interface.

At its core, the architecture relies on a continuous evaluation loop. The model isn’t just generating an answer; it’s navigating a Gather-Act-Verify cycle. (2)

graph TD
    A[User Input / Prompt] --> B(Agent Harness Control Loop)
    B --> C{LLM Decision Engine}
    
    C -- Needs Context --> D[Gather]
    D --> D1(Search Files, Read Memory)
    D1 --> B
    
    C -- Ready to Execute --> E[Act]
    E --> E1(Write Code, Run Terminal)
    E1 --> B
    
    C -- Needs Validation --> F[Verify]
    F --> F1(Run Tests, Check Linting)
    F1 -- Error Found --> B
    F1 -- Success --> G[Final Response to User]

Another crucial component of this architecture is Memory Management. Developer Simon Willison highlighted a fascinating architectural detail in a recent blog post comparing the memory implementations of Claude and ChatGPT. (2)

Claude’s harness philosophy prioritizes extreme transparency. Unlike OpenAI, which often injects user profiles or past context into the background automatically, Claude Code starts every conversation as a blank slate. Memory is implemented as explicit tools (specifically conversation_search and recent_chats).

sequenceDiagram
    participant User
    participant Harness
    participant LLM
    participant MemoryDB
    
    User->>Harness: "Continue where we left off yesterday"
    Harness->>LLM: Pass user prompt
    LLM->>Harness: Tool Call: conversation_search()
    Harness->>MemoryDB: Query past logs
    MemoryDB-->>Harness: Return relevant context
    Harness-->>LLM: Inject context into prompt
    LLM->>User: "Ah yes, we were fixing the routing bug..."

Because the model decides when to pull from memory via a visible tool call, you avoid the issue of old “bug loops” silently poisoning a fresh workspace.

Building Your Own Agent Harness and the benefits

But why should you build your own agent harness when they already exist and work fine? I think its just the same reason why open source software exists. Closed-source systems like Claude Code are incredibly powerful, but they are highly opinionated and tailored to specific workflows (like general software development). By building your own, you gain maximum flexibility.

You can customize the exact tools the agent has access to, perhaps integrating it directly with your company’s proprietary databases, Jira ticketing systems, or internal APIs. Or you can just adjust it for your needs for software developement or general purpose use. Fortunately, you don’t have to start from scratch. An excellent starting point is the GitHub repository RyanAlberts/best-of-Agent-Harnesses. (4) This curated, weekly-updated list ranks over 100 open-source agent harnesses. Notably, it even includes an MCP (Model Context Protocol) server, llms.txt, and JSON data, allowing agents themselves to read the repository and recommend the best harness framework for your specific needs.

For what would i use a “Harness” for?

To understand the practical value, let’s look at a real-world project I am doing at work: a system designed to fully automate the production of AI-generated videos.
To be honest, the architecture diagram below represents a highly structured pipeline rather than a full-blown autonomous harness, because I have to make it highly predictable. However, it perfectly illustrates the foundational steps. By giving the central “Orchestrator” more flexibility and decision-making power, this pipeline could easily evolve into a true agentic harness.

How would this be agentic then if we give it more freedom to be “creative”. If we apply the Gather-Act-Verify principles discussed earlier to this exact diagram, the system becomes truly autonomous:

• Gather (Data & Script Prep): Instead of just following a static script, the agent uses tools to autonomously query the AWS Database for the latest product stats and fetches the correct Presentation Assets (potentially using the Model Context Protocol, MCP, to search through company directories).
• Verify (Validation & Creation): This is where a harness shines. In a rigid pipeline, if the Small compliance/Legal check fails, the system just throws an error and stops. In an agent harness, the LLM catches this error, analyzes why the script failed compliance, and autonomously rewrites it until it passes the check.
• Act (Audio, Sync & Rendering): Once the agent verifies the script is perfect, it triggers the text-to-speech tools, gathers the exact audio timestamps, and hands everything over to the rendering engine before finally publishing it.

Challenges and Best Practices

If you decide to build a custom harness, keep these best practices in mind:

1. Cost and Latency Control: Because the agent runs in continuous loops (sending accumulating context back to the model), API costs can skyrocket. Implementing effective Prompt Caching is mandatory. (5)
2. Robust Error Handling: If a tool (e.g., a terminal command) fails, the harness must not crash. It needs to gracefully catch the error (like a stack trace) and feed it back to the LLM during the Verify phase so the agent can self-correct. (5)
3. Transparency: Follow Claude’s example. Don’t hide memory injections in the system prompt. Implement memory and context retrieval as visible tool calls so users can audit what the agent is doing. (6)
4. Sandboxing: Because the Act phase allows the execution of commands, your harness must enforce strict security boundaries (e.g., running actions inside Docker containers) to prevent an autonomous agent from accidentally deleting critical system files. (5)

Conclusion

An agent harness is much more than an API wrapper, it is the vital infrastructure that gives a language model the tools it needs. While leaks and teardowns of commercial tools like Claude Code give us a glimpse into high-end, proprietary architectures, the vast open-source community proves that custom, bespoke solutions are more accessible than ever. By mastering the Gather-Act-Verify loop and maintaining clean, transparent tool management, you can transform a simple text generator into an autonomous, specialized digital colleague.

Btw: There is also a very good video if you want to know more about harnesses from Langchain: https://www.youtube.com/watch?v=HI2q3ci3Iuc&t=409s

Sources

1. https://vrungta.substack.com/p/claude-code-architecture-reverse
2. https://michaellivs.com/blog/architecture-behind-claude-code
3. https://www.mindstudio.ai/blog/claude-code-source-leak-memory-architecture
4. https://github.com/RyanAlberts/best-of-Agent-Harnesses
5. https://resources.anthropic.com/building-effective-ai-agents
6. https://simonwillison.net/2025/Sep/18/agents/

The post Creating your own custom Agent Harness like Claude Code and why it matters appeared first on Mobile USTP MKL.

When I started out, I decided to make an application that was really worth trying. I designed a database structure and a system architecture that I meant to be perfect. But for my first frontend (tbh not only the frontend), I was struggling. I am no designer myself and couldn’t really create a smooth user flow, so I used AI to help me with that. After I was done, I wasn’t very happy with either the scalability or the look and feel. I had used Ionic, a web framework that ran in a WebView on the device. The touch inputs didn’t feel instant or responsive enough, and for what was basically a simple CRUD app, it felt a little bit sluggish (or maybe that’s just me).

So, in my second semester, I focused on refining that whole experience and making it better in every way.

The Rewrite: Embracing Kotlin Multiplatform

I decided on a new frontend framework: Kotlin Multiplatform (KMP), which allows you to build apps for nearly any platform using a shared codebase. I also added new features, like self-hosted AI solutions to generate content and a posibility to choose your current Gym.

Implementing my app with Kotlin was challenging because it was a completely new programming language to me. After learning the fundamentals and coding on my own for the first week, I brought in some AI coding agents to help speed up the process. At first, I used a local model called qwen3-coder:30b, which I quantized to run on constrained hardware. My setup was a Mac Book Air M1 from the USTP rental service running OMLX (which was especially built for Macs to take advantage of their unified memory). Running in my IDE was the open-source AI code agent Continue, which allowed me to implement MCP servers and feed code context from my project to the model. Later I learned that this extention or IDE whatever you wanna call it, is no longer being developed and was acquired by Cursor.

After I sadly had to return the rental Mac (originally i wanted to use it for building the App for IOS as well but just failed to finish the App in time ) , I switched to Claude Code. For me, it was essential to double-check Claude’s work and architectural decisions. Honestly, I was a little bit shocked by some of the choices it made, like trying to store API keys or passwords in plain text just somewhere in the Code! To be fair, I wasn’t using their frontier model to avoid spending too many tokens (as I argued a lot with it during the development process), but still. However, it was particularly handy for creating the frontend layer with Jetpack Compose, thanks to the vast documentation available for Android’s UI framework.

To avoid hallucinations and provide the model with up-to-date documentation, I added an MCP Server called Context7. It allowed me to filter exactly what documentation the model received and what it had access to … a really handy tool.

Frontend Challenges: Caching, Offline Sync, and Navigation

The hardest part of my frontend implementation was the caching logic. I wanted the app to always instantly display the relevant information you need in the moment. To achieve this, I decided to cache the first 10 items of every category (e.g., Templates, Trainings, UserData).

All of this is stored in a Key-Value database called KStore, a small library that works great for simple data storage on Android and iOS devices. The absolute hardest part was defining the behavior for when I saved something offline, ensuring that the moment I got back online, it would post to the backend so the two storages would “sync” up again. We now have a (mostly) robust network-first cache strategy with offline fallbacks.

I also completely revamped the app’s navigation and UI architecture using Compose Multiplatform:

• Two-Level Navigation: We have an outer navigation graph for the Auth-Flow (Login/Register) and an inner graph wrapped in a Scaffold for the main tabs. This allows for a persistent BottomBar that stays visible while you switch tabs.

• Profile Dialog: Instead of routing to a new screen, the user profile opens as a clean Dialog Card over the current screen, making it feel much faster.

• Security: Tokens are stored securely using KVault (Keychain for iOS, EncryptedSharedPreferences for Android).

• Dependency Injection: I used Koin to keep the architecture clean (MVVM), allowing the UI to remain logic-free.

The Backend: Keeping it Clean & Adding a Scraping Service

For my backend (a self-hosted NestJS API), I tried to make major improvements to security and code cleanliness. Most of my backend wasn’t even touched by AI … I mean aside from a few MongoDB queries … they’re just really weird to write ok? … so I could assure everything was up to my expectations.

For extended features, I added a custom scraping service using a separate Python server. It scrapes all the fitness studios listed on my gym’s website and writes everything about their equipment directly into my database. It’s scheduled to run on startup and then one time per Month (don’t want to get accused of creating to much net traffic for them). I deployed this service in a separate Docker container within the same Docker network to ensure minimal downtime in case the scraper ever crashes.

Building a Local AI Agent for Training Templates

Having the exact context of my gym’s equipment in the database was especially helpful for my next big feature: Local AI Training Template generation.

To be honest, I initially wanted to use the MCP server I had programmed earlier for this task. But by the time I got to implementing the AI feature, I realized that Ollama doesn’t actually support MCP natively because it lacks an MCP client.

So, I built an Agentic loop directly in my NestJS backend to act as a middleman between Ollama and my server. I could have gone the route of calling my MCP server through my backend and called it a day. But after a short “question battle” with Claude Code, I decided that wasn’t feasible due to the unnecessary network requests I could save by just implementing the agent loop directly in the backend.

My custom MCP Server now exists on its own and isn’t connected to anything just yet. But building it was a fantastic learning experience regarding how these systems work. It lays the groundwork for future implementations, as I eventually plan to integrate external MCP-capable AI tools like Claude or ChatGPT.

Technical Deep Dive: Gymetrics Feature List

For those interested in the exact tech stack and architectural decisions, here is a breakdown of what’s running under the hood:

The Stack

• Frontend: Kotlin Multiplatform, Compose Multiplatform (Shared UI), targeting Android (first priority) and iOS.
• Backend: Self-hosted NestJS API with Dockerized microservices.
• Auth: Short-lived Bearer tokens + Refresh tokens.

Core Implementations

• Ktor Client & Auto-Refresh: Centralized HTTP client handling JSON serialization, timeouts, and dynamic base URLs. Used the Ktor Auth plugin to automatically attach tokens and trigger a silent refresh route (POST /auth/refresh) on 401 errors.
• Offline-First Capabilities: Built a custom ConnectivityObserver that tracks network state app-wide. The app displays an offline badge in the TopBar and handles offline Auth checks by optimistically trusting the securely stored token.
• App-Wide Theming: Implemented a custom GymetricsTheme wrapper around MaterialTheme, featuring a sleek, app-wide dark mode and adaptive Android icons.
• State Management & DI: Strict MVVM architecture. State is handled via sealed interfaces and exhaustive when statements (Idle/Loading/Success/Error). Dependency Injection is handled entirely by Koin (using appModule, single, and viewModelOf).

It’s been a massive journey from a simple Ionic prototype to a fully-fledged, offline-capable KMP application with agentic AI workflows. It started as a way to replace a spreadsheet, but it taught me modern mobile architecture, backend, and how to effectively wrangle AI coding assistants.

The post Gymetrics: A Self-Hostable Fitness App with Kotlin Multiplatform, NestJS, and Dockerization appeared first on Mobile USTP MKL.

On-device artificial intelligence (AI) is a system that works on mobile devices, such as smartphones and laptops, as well as other wearables. It is more independent because it can be used on the go without an internet connection. This is just one of the advantages of these systems. Another is the privacy benefits of local processing, as there is no outgoing data traffic or need to store user or sensitive data on remote servers. Local AI also has the advantage of lower latency compared to cloud models. Due to its built-in nature, it can be very fast (of course, depending on the device), and eliminates the additional costs that a cloud model would inevitably incur.

Another use case for local models would be assistance through “ambient computing”, where the device anticipates user needs based on on-screen context.An example is Magic Cue on Android 16, which runs locally to offer relevant actions based on the user’s current activity.

Technical Background:

Deploying Large Language Models (LLMs) locally requires overcoming significant hardware constraints, specifically limited memory or RAM, battery life, and thermal limits. To run models larger than the device’s physical RAM, frameworks use flash storage to store the needed data, dynamically loading only the “active” weights needed for the current token generation into RAM. This allows devices with limited RAM (e.g., 8GB) to run larger models. Also specific cpus with dedicated Neural Processing Units (NPUs) like the Snapdragon 8 Gen 3 utilizing these to squeeze out a little bit more performance to run even bigger complexer models. They are also faster in delivering higher token-per-second rates. Google famously focused their chips called Tensor to have Tensor Processing Units which results in even better performance and efficiency for their models across the board.

Quantization

But how can you fit large models onto such a tiny device while taking hardware concerns into account? It works with quantisation. This technique compresses a model to a much smaller size. It’s much like compressing a folder or file into a zip file on your PC. AI models are normally trained using a format called FP32. If you have a ‘7 billion parameter’ model (such as Llama 3 or Qwen), each parameter requires 4 bytes. However, when you do the maths with such a model: 7 billion x 4 bytes = 28 GB of RAM. However, most smartphones only have 8 or 12 GB of RAM in total, and even if they share some of the normal SSD memory, the model simply will not fit. Quantisation is the process of converting these large models from FP32 to INT8 or INT4. Going from 32-bit to 4-bit usually results in very little loss of intelligence, often less than a 1% drop in accuracy. Alternatively, you can think of the process as compressing an image. Most of the detail remains; only the extreme details are lost in the process.

Software and Ecosystem:

Local AI is supported by a software stack designed to abstract hardware complexities.
Google’s Gemini Nano is a prime example of a multimodal model developed specifically for on-device efficiency. It comes in different sizes to accommodate different devices and their performance capabilities. Frameworks such as LiteRT-LM enable developers to create custom LLM pipelines that can be used on Android, iOS and web platforms. LiteRT-LM is a relatively low-level tool that is not commonly used by developers. The ML Kit GenAI API is a more commonly used tool for this purpose, leveraging local models. It offers native APIs for Kotlin/Java, Swift and JavaScript, enabling deployment of the same model across different platforms. However, there are also different options available for each ecosystem.

Android

ML Kit GenAI API is probably the most straightforward and user-friendly toolset to implement for Android developers in particular. It completely abstracts away model management by interfacing with Android AICore. As it uses the built-in Gemini Nano model, there is no need to bundle a large model with your app. It offers pre-built APIs for common tasks, so there is no need to design prompts. These include summarising text passages, proofreading, rewriting, and providing smart replies. If you require greater flexibility than that offered by the above-mentioned specific tasks, the GenAI Prompt API enables you to send natural language requests directly to Gemini Nano.

Web
For web applications, Google is integrating high-level AI capabilities directly into the Chrome browser. Similar to the Android approach, this allows web developers to access on-device Gemini Nano models through JavaScript APIs without requiring the user to download heavy libraries or models for each site.

iOS

For iOS 18+, developers can use system-level APIs to access Apple’s on-device foundation models for text generation and embeddings, removing the need for third-party libraries

While Google promotes the ML Kit GenAI API for Gemini, the API explicitly supports “other open models” and “open-weight models” like mistral, llama or gemma. It just abstracts the complexity of the low-level LiteRT-LM engine to be accessible to more developers.

Conclusion:

On-device AI represents a critical step forward for user sovereignty. By processing data locally on dedicated NPUs, we eliminate the need to send sensitive information to remote servers, solving the twin challenges of latency and privacy in one go. While tasks requiring immense computational power will remain in the cloud, the “thinking” that happens on our smartphones is getting smarter, faster, and more personal. For the end user, this means a device that is not just a portal to the internet, but a truly intelligent assistant that works anywhere, anytime.

References:

• https://www.applivery.com/blog/news/google-pixel-10/
• https://www.researchgate.net/profile/Dwith-Chenna/publication/373329073_EDGE_AI_QUANTIZATION_AS_THE_KEY_TO_ON-DEVICE_SMARTNESS/links/64e627b60453074fbda950d6/EDGE-AI-QUANTIZATION-AS-THE-KEY-TO-ON-DEVICE-SMARTNESS.pdf
• https://arxiv.org/html/2512.06490v1
• https://developers.googleblog.com/on-device-genai-in-chrome-chromebook-plus-and-pixel-watch-with-litert-lm/
• https://nearform.com/digital-community/ai-beyond-the-cloud-the-current-and-future-state-of-on-device-generative-ai/

The post Technical Revolution – On-Device AI appeared first on Mobile USTP MKL.

Goals

As the Key Goals I identified some Basic Functionality I wanted to have completed at the end of the Semester:

• Help people to store their own data on their own systems
• Develop a functional App with Ionic and Angular
• Build a good foundation that could be expanded with other features later

Progress

During development, I encountered some setbacks which slowed down the process slightly. However, I fundamentally achieved everything I set out to do. I developed and implemented a really good RESTful backend foundation that can be used to build future features on top of, and it was designed with expansion in mind. Furthermore, I developed a coherent design language for my Ionic frontend application.

Features

The fundamental concept of my app is creating and tracking workouts. This is achieved as follows:

First, you can create a template in the Workout section. Then you can assign a title and description with a specific character limit. Then you can plan different exercises, each with a distinct weight and number of repetitions. In future, I also want to include options for choosing the length or time of a single exercise instead of the weight or reps. Once you have created the template, you can save or discard it, or delete it completely.

Once you have created the different templates, you can assign them to different dates in the Calendar tab. This tab is currently under construction and will be improved for better readability in the future, but it is like this for reasons of time constraints. Here, you can select a template and a workout, which will then be added to the calendar on this date.

Once you have created the training, you can go to the ‘Home’ page to see when your next training session is scheduled and to start it. While started you can edit the done weight and reps and save it after you are done with the exercise:

Conclusion:

I was surprised by how much effort it took to get to this point. Building something from the ground up with many future features in mind broadened the scope of the initial project setup, and this wasn’t easy for me. The backend in particular took some time because I wasn’t very familiar with the framework and the concept as a whole. Setting up everything in Docker containers and making them communicate with each other also took some time, but it wasn’t as challenging as the other parts because I have some experience with this technology already. So what have I completed from my inital Goals and what have i learned? In my project description, I stated that my app should contain account creation, repetition scheduling for training sessions, and a customisable point system.

• Creating an account was not really a problem. I also enhanced the security of the application by implementing authentication via a short-lived JWT (JSON Web Token) and a refresh token that could be used to refresh the JWT and extend the active session, thereby preventing the user from having to log in constantly.
• During the development process, I questioned the point of having recurring training sessions, as I prefer to plan my training in advance, but my schedule changes every week. I would also like to be able to adapt the template or adjust the weights or repetitions according to my performance in the previous session. As this feature didn’t make much sense, I changed it so that I can create training sessions by clicking on the calendar.
• Sadly, the customisable point system fell a little short due to my limited time, but I still want to implement a good statistics system in the future. I’ve also prepared everything for the factor that I can apply to each exercise to alter the ‘score weight’.

But what have I learned?
I’ve learned the hard way that planning is absolutely everything, no matter how big your project is. The database structure and the architecture of an application are important things to consider when starting a new project, and will save so much time during development. I’ve also gained a good understanding of NestJS and its use with MongoDB, although there’s still a lot more to learn.

Outlook and future Features

Not only because i want to use this application for myself in the future but also because i really had fun programming it i have many Ideas for the next features.

• Firstly, I would like to create a better calendar page for creating new workouts and viewing a weekly overview of future training sessions.
• Another important feature would be the ability to reset your own password and confirm your email address.
• I want to implement scoring and analytics for my workouts to track
• I also want to add a locally connected LLM through Ollama to recommend training, exercises or tips based on completed workouts and user profiles containing all the relevant health data.
• Improve the security within the Docker Network and the instances itself

The post Gymetrics | self-hostable fitness tracker: semester one progress appeared first on Mobile USTP MKL.

With the enforcement of the European Accessibility Act (EAA), digital accessibility has shifted for many companies from just a recommendation to a necessity. This article provides an overview of the current state of web accessibility grounded in Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2, the gold standard for the EAA. The article lists the core principles and conformance levels, examines the limitations of current testing methodologies, and identifies weaknesses. Specifically, it addresses the reliance on human evaluation and the related expert problem due to automated tools’ inability to detect more than 20 to 50 percent of violations. The article also reviews modern implementation strategies, such as integrating testing engines like Axe-Core into CI/CD pipelines, and addresses the lack of inherent accessibility support in modern front-end frameworks. Finally, the paper offers an outlook on the evolving WCAG 3.0 standard and explores the transformative potential of AI and large language models (LLMs) in assisting developers and improving assistive technologies.

1. Introduction

The topic of accessibility in modern web technologies is more relevant than ever. With the European Accessibility Act (EAA) already in effect, many companies must take action [4]. The goal is for every company with more than ten employees and a turnover of over two million euros to comply with these rules. This ensures that the web is accessible to everyone. However, there are many challenges to implementing web accessibility after a website or web app has been developed; it can be very costly and time-consuming to do so. To address these challenges, this article analyzes the current landscape of web accessibility under WCAG 2.2, specifically identifying weaknesses in testing methodologies and the reliance on human evaluation. Furthermore, it outlines future advancements by exploring the flexible WCAG 3.0 standard and the transformative potential of AI and Large Language Models in development.

2. Web Accessibility Definition

As stated by Petrie, Savva, and Power (2015), accessibility on the web is a set of rules that, when followed, ensures that all people, particularly those with disabilities and the elderly, can use websites in a variety of contexts, including mainstream and assistive technologies [7].

2.1 WCAG

A cornerstone in the realm of accessibility are the Web Content Accessibility Guidelines (WCAG). Developed by the World Wide Web Consortium (W3C), these guidelines provide a standardized procedure for creating accessible internet offerings.

Over the years, the standards have been reworked several times. The current standard required by the EU in the EAA is WCAG 2.1 [8]. For uniformity purposes, this article focuses on the more current WCAG 2.2. This standard relies on four base principles that are summarized by the acronym “POUR” and contain the following points:

• Perceivable: The information and user interface components must be presented to users in a way that they can perceive.
• Operable: The user must be able to handle the user interface components and the navigation.
• Understandable: The information and the handling of the user interface must be understandable.
• Robust: The content must be robust enough that it can be reliably interpreted by a wide variety of user agents, including assistive technologies.[8]

2.2 The WCAG 2.2 Guidelines in Detail

To fully grasp the topic and its inherent challenges, it is essential to understand the core principles. To ensure a positive experience for every user, evaluations should use specific Success Criteria. This creates a repeatable test to verify that a product conforms to WCAG rules [13]. The key criteria for each principle are as follows:

2.2.1 Perceivable

• Text Alternatives: Requires providing text alternatives for any non-text content (such as images, icons, or input elements) so that it can be transformed into other forms people need, such as large print, Braille, speech, or symbols.
• Time-based Media: Requires providing alternatives for time-based media. This includes providing captions, audio descriptions, and potentially sign language interpretation.
• Adaptable: Content must be created in a way that allows it to be presented in different formats without losing information or structure. This can be achieved with different layout options, for example. Ensuring that the information and structure can be programmatically determined by assistive technology is key.
• Distinguishable: This ensures that it is possible for every user to distinguish the different elements of a digital product from others. That could be achieved by a good contrast ratio, providing the controls attribute for audio elements, and enabling users to change the size of displayed text.

2.2.2 Operable

• Keyboard Accessible: All functionality must be available from a keyboard interface. Providing universal keyboard input is crucial because no other input form offers the same flexibility or is universally supported by people with different disabilities.
• Enough Time: Users must be provided enough time to read and use content, since many users with disabilities require more time to respond, read, or use assistive technology. This can be a problem with automatically disappearing popups or toast messages.
• Seizures and Physical Reactions: Content must be designed to avoid causing seizures or physical reactions, primarily by restricting flashing visual content.
• Navigable: Users must have ways to help them navigate, find content, and determine where they are. This includes ensuring logical focus order, clearly defined headings and labels, and the ability to bypass blocks of repeated content. A good test for this would be trying to navigate a webpage with just the tab key.
• Input Modalities: This requires making the functionality operable through various inputs beyond the keyboard, such as touch, a stylus, or a mouse pointer. This includes providing alternatives for complex pointer gestures, such as drag-and-drop, and ensuring that target sizes are large enough for touch input.

2.2.3 Understandable

• Readable: This aims to ensure that text can be read by screen readers and other assistive technologies.
• Predictable: This guideline focuses on achieving a consistent, repeatable way to interact with webpages.
• Input Assistance: Must help users avoid and correct mistakes. Since people with disabilities may have more difficulty creating or detecting input errors, this guideline requires effective error identification, providing instructions and labels, and error prevention features, particularly for legal or financial transactions. Logical error messages and suggestive labels are a good way to start.

2.2.4 Robust

• Compatible: Due to the rapid changes in modern technology, developers of assistive technologies are struggling to keep up. Thus, the primary focus of this guideline is maximizing compatibility with current and future user agents.
• Technical Compliance: Robustness means ensuring content adheres to conventions so that assistive technologies can reliably recognize and interact with elements.[15]

3. Compliance via WCAG 2.2

Compliance via Web Content Accessibility Guidelines is determined by satisfying its success criteria, which were explained previously [12].

3.1 Conformance Level

To achieve full compliance, the content must meet five conformance requirements. It is possible to conform at different levels and in different categories. However, to fulfill each level, all associated rules must be applied.

• Level A: Contains, for example, all necessary labels and tags that can be associated with the HTML code. No conformance to WCAG is possible without at least satisfying all the Level A success criteria.
• Level AA: The content must satisfy all the Level A and Level AA success criteria. This is the industry standard and the minimum requirement for a WCAG-compliant webpage. It also meets the standards of the EAA because they are based on WCAG Level AA [4].
• Level AAA: All content must satisfy the Level A, Level AA, and Level AAA success criteria. One example of a required service is providing sign language interpretation for all videos and audio content.

For any of these levels, conformance can alternatively be achieved if a conforming alternate version is provided [12].

3.2 Testing Procedures

While accessibility testing is frequently conducted manually through human inspection [1], standardized automated tools also play a valuable role. However, human evaluation remains the best practice, as automation alone is often insufficient. Although automated tests offer significant advantages regarding scalability and integration into the development lifecycle, they frequently fail to detect crucial compliance issues [14]. Consequently, directives such as the European Accessibility Act explicitly require human involvement for validation [3].

4. Challenges in the Current Guidelines

The current Web Content Accessibility Guidelines pose several significant challenges related to their objective testability, consistent implementation, and overall scope.

The fundamental issue with the reliability of the WCAG 2.0 guidelines is its review and testing process. Although the process is partially automated, it still relies heavily on human judgment [1].

The current rules define reliable human testing as when 80 percent of evaluators agree on a website’s compliance. However, empirical studies have shown that approximately 50 percent of WCAG 2.0 success criteria fail to reach this threshold, even when evaluated by accessibility experts. Another issue is the high level of expertise needed to assess conformity [1].

Another significant challenge in passing some tests is the binary approach of WCAG 2.0. Evaluators can only give a pass or fail for each level of conformance [10].

5. The Future Standard: WCAG 3.0

To address these issues, the W3C began developing a new standard called WCAG 3.0. Although it has not yet been released, the first working draft was published in September 2025. The finished guidelines are expected to be released in a few years [5].

5.1 Shift in Philosophy

The new standard aims to move away from rigid rule sets and the traditional “pass/fail” paradigm. Instead, it focuses on a user-centered approach that prioritizes core functionality and the specific needs of individuals using assistive technology. Additionally, the guidelines are intended to support a wider range of disabilities by providing more personalized and adaptable experiences. This flexibility helps it remain relevant as technology evolves over time [11].

Moreover, the standard is designed to regulate not only web applications but also software in general, including smartphone apps and desktop programs. The guidelines cover accessibility across a variety of hardware, ranging from desktops, laptops, and tablets to wearables and Internet of Things (IoT) devices. They also apply to diverse content types, such as static, dynamic, interactive, and streaming media, as well as virtual and augmented reality [11].

WCAG 3.0 intends to build on the current foundations and incorporate accessibility overlays. These overlays can make websites more accessible without redoing previous work, thereby simplifying implementation [10]. However, it is important to acknowledge that this technological approach under the current WCAG 2.2 faces significant criticism within the community. Many experts argue that it does not replace the necessity of intrinsic accessible design [6].

5.2 New Scoring System

The new conformance model will fundamentally change how things are evaluated, building upon similar requirements to the current norm. Since the ruleset and evaluation criteria are still being developed, only a few details are known about how it will work.

The proposed model for WCAG 3.0 conformance is based on three main components:

• Foundational Requirements: These constitute the most basic level of conformance.
• Supplemental Requirements: These are used, alongside Assertions, to define and meet higher levels of conformance.
• Assertions: These are defined as a formal claim of fact, attributed to a person or organization, regarding documented procedures practiced in the development and maintenance of the content or product to improve accessibility.

The main differences and similarities can be seen in Table 1.

Table 1: Comparison of Conformance: WCAG 2.2 vs. WCAG 3.0

Sources: [5, 10, 12]

6. State-of-the-Art Implementation

6.1 Modern Tooling and CI/CD

To ensure inclusivity from the beginning, the best practice is to include automated tests in CI/CD processes. These approaches can identify common issues early on, provide continuous feedback, and are easily scalable [9].

Ci-Accessibility stated that there are many accessibility tools available and suitable for integration into automated testing frameworks:

• Deque Systems’ Axe-Core CLI: This open-source accessibility testing engine is designed to work across modern web techniques and supports WCAG 2.0, 2.1, and 2.2 levels A, AA, and AAA. Axe was found to be among the easiest tools to integrate into a CI/CD workflow, such as using GitHub Actions. It provides good descriptions, precise locations for errors, and links to further documentation, making it highly valuable.
• Squiz Labs’ HTML_CodeSniffer: This tool checks HTML documents for accessibility violations based on rule-sets encompassing the three conformance levels of WCAG 2.2. It can be integrated into a CI pipeline, although it may require additional configuration and coding compared to tools like Axe.
• IBM’s Equal Access Accessibility Checker: This tool consists of open-source components that validate web code against accessibility concerns, complying with WCAG 2.2 levels A and AA. Along with Axe, it was noted as one of the easiest tools to integrate into a CI/CD pipeline.

A comparative study on integrating tools into a GitHub Actions CI/CD workflow found that Axe demonstrated the best overall performance in detecting WCAG violations among the tools tested [9].

All of these options can also be used on the client side to provide easy verification of finished products or to support human evaluations. Despite the advancements in tool integration, automated accessibility tools have significant limitations, underscoring why human expertise, as discussed before, remains critical to comprehensive success. Automated tools can only detect a fraction of Web Accessibility guideline violations. A study found that selected open-source evaluation tools detected, on average, approximately 20 percent of all errors present on a given web page. This falls within the expected range, as accessibility experts note that only 20 percent to 50 percent of all accessibility issues can be automatically detected. Automated tools can produce false positives or false negatives, further reducing the accuracy of the results [9].

6.2 Role of Modern Frontend Frameworks

While specialized tools (often integrated as linters or automated testing components) are essential for checking WCAG conformance, modern frontend frameworks themselves currently provide minimal inherent accessibility support during the development process, as shown in the study of Support-Webframeworks. The testing of modern front-end frameworks (Angular, React, and Vue) was an empirical study designed to evaluate the extent to which they support developers with automated accessibility features during the development process. The study focused on creating inaccessible web applications on purpose and observing whether the frameworks generated internal feedback about the violations. Each framework was configured using its default settings at installation. All development was carried out in Visual Studio Code. The study concluded that the three frameworks offered almost no feedback regarding accessibility violations. React was the only framework able to detect an issue, generating a single warning for the WCAG 1.1.1 Non-text Content violation. This violation occurred due to the absence of a label for non-text content.

The current draft of WCAG 3.0 acknowledges this issue and aims to address it through a holistic, technology-agnostic approach [11].

6.3 Role of Artificial Intelligence

In the study of AI, AI coding assistants, such as GitHub Copilot, are being explored for their potential in creating more accessible user interfaces. A prototype Visual Studio Code extension has been introduced that integrates an LLM to help developers identify and resolve accessibility issues. Similarly, the CodeA11y GitHub Copilot Extension has been developed to make AI coding assistants useful for accessible web development. The most frequent use case leverages LLMs to automatically generate high-quality alternative text for complex web images or labels for different actions in the HTML code. AI-based techniques can also significantly reduce the need for manual checks in accessibility testing by integrating seamlessly into automated environments.

AI can also be integrated into assistive technologies and conversational agents to offer new opportunities for improving accessibility. For instance, AI-assisted speech recognition and conversational AI have demonstrated the ability to overcome the limitations of traditional screen readers, thereby increasing the inclusivity of web resources for blind and visually impaired users [2].

7. Conclusion and Outlook

As of now, the current WCAG 2.2 standard has many weaknesses due to rapid changes in modern technologies, but it remains a very important milestone in making the digital world accessible for everyone. The testability of some applications is slowed down or becomes impossible when human evaluators disagree. Additionally, the binary ‘pass or fail’ nature of the criteria stated, often leads to failed tests. The future of digital accessibility lies in the W3C Accessibility Guidelines (WCAG) 3.0. This new approach, which is currently under development, is a significant evolution toward a framework that is more user-centric, flexible, and not dependent on a specific technology. It tries to address issues with the scoring system and enables better support from frontend web frameworks and AI-driven CI/CD tools, to warn developers from non-compliant code. Complementing this evolution, AI coding assistants and LLMs are becoming essential for automating tasks like alt-text generation, while AI-integrated assistive technologies are overcoming screen reader limitations to further enhance inclusivity for visually impaired users.

References

[1] Brajnik, G., Yesilada, Y., & Harper, S. (2010). Testability and validity of WCAG 2.0: the expertise effect. In Proceedings of the 12th international ACM SIGACCESS conference on computers and accessibility (p. 43–50). New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/1878803.1878813

[2] Campoverde-Molina, M., & Luján-Mora, S. (2025). Artificial intelligence in web accessibility: A systematic mapping study. Computer Standards & Interfaces, 96, 104055. https://doi.org/10.1016/j.csi.2025.104055

[3] European Commission. (2025). Web accessibility shaping europe’s digital future. Retrieved 2025-12-03, from https://digital-strategy.ec.europa.eu/en/policies/web-accessibility

[4] European Union. (2019). Richtlinie (EU) 2019/882 des europäischen parlaments und des rates vom 17. april 2019 über die barrierefreiheitsanforderungen für produkte und dienstleistungen (Vol. 151). Retrieved 2025-12-03, from http://data.europa.eu/eli/dir/2019/882/oj

[5] Initiative (WAI), W. W. A. (2025). WCAG 3 introduction. Retrieved 2025-12-04, from https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/

[6] Makati, T., Tigwell, G. W., & Shinohara, K. (2024). The promise and pitfalls of web accessibility overlays for blind and low vision users. In Proceedings of the 26th international ACM SIGACCESS conference on computers and accessibility (pp. 1–12). New York, NY, USA: Association for Computing Machinery. https://doi.org/10.1145/3663548.3675650

[7] Petrie, H., Savva, A., & Power, C. (2015). Towards a unified definition of web accessibility. In Proceedings of the 12th international web for all conference (pp. 1–13). Association for Computing Machinery. https://doi.org/10.1145/2745555.2746653

[8] Routledge Open Research. (2022). The EU accessibility act and web. Retrieved 2025-12-03, from https://routledgeopenresearch.org/articles/1-30

[9] Sane, P. (2021). A brief survey of current software engineering practices in continuous integration and automated accessibility testing. In 2021 sixth international conference on wireless communications, signal processing and networking (wispnet) (p. 130-134). https://doi.org/10.1109/WiSPNET51692.2021.9419464

[10] Sikder, A. S. (2023). The evolution of web accessibility guidelines: A comparative analysis of WCAG 2.0 and WCAG 3.0 in ensuring inclusivity on the web. International Journal of Information Science and Technology, 1(1), 170–185. https://doi.org/10.70774/ijist.v1i1.18

[11] W3C. (2025). W3C accessibility guidelines (WCAG) 3.0. Retrieved 2025-12-04, from https://www.w3.org/TR/wcag-3.0/

[12] W3C Web Accessibility Initiative (WAI). (2025a). Understanding conformance. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/conformance

[13] W3C Web Accessibility Initiative (WAI). (2025b). Understanding techniques for WCAG 2.2 success criteria. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/understanding-techniques

[14] W3C Web Accessibility Initiative (WAI). (2025c). Understanding test rules for WCAG 2.2 success criteria. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/understanding-act-rules

[15] W3C Web Accessibility Initiative (WAI). (2025d). Understanding WCAG 2.2. Retrieved 2025-12-03, from https://www.w3.org/WAI/WCAG22/Understanding/

The post SOTA | Modern Web Accessibility appeared first on Mobile USTP MKL.

Idea

I tried to use the well-known store IKEA and its Catalog to implement my idea. This project aims to bridge the gap between physical catalogs and digital visualization. The core concept involves using QR codes placed on the product pages to link to an external web application. Once the user scans the code, this application can display a 3D model of the product above its corresponding picture in the physical catalog.

Implementation

For technologies, I used HTML, CSS and JavaScript. For the purpose of pattern recognition and tracking, I used the framework mindAR.js. For displaying the 3D Objects, I used the framework A-Frame. Sadly, the 3D objects that I used are very high fidelity and that impacts the performance of the application. So when you want to scan the furniture elements on the page, you have to be very careful, not to move too much or too quickly. It’s hosted on my own server as a docker instance using a Nginx web server.

Link to the Webapplication: https://.ikea-scanner.laschober.eu

Disclaimer: This project is not affiliated with, endorsed by, or in any way officially connected with IKEA. The use of IKEA’s name and catalog images is solely for illustrative purposes as a practical example for the proof of concept.

The post Print2Mobile | AR – Web Application to project 3D Objects onto a Catalog appeared first on Mobile USTP MKL.