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.