AI chatbots for school accessibility: open vs proprietary

Schools are under pressure to make digital services usable by students with disabilities, defensible under data-protection rules, and maintainable after the original implementation team has moved on.

The legal picture is more specific than the headlines suggest. The European Accessibility Act became applicable on June 28, 2025, but it does not automatically place every chatbot, school website, or internal public-sector tool within the same obligation. The Act covers defined categories of products and services supplied to consumers. Whether a particular education platform or chatbot falls within its scope depends on the service being provided, the organisations involved, and the relevant national implementation and enforcement arrangements.

That distinction matters. It prevents schools from treating a compliance date as a substitute for an accessibility programme. It also changes the open-source versus proprietary decision. Open-source platforms offer control, customization, and data sovereignty. Proprietary platforms offer speed, vendor accountability, and pre-built compliance documentation. Neither path removes the need for testing. The difference lies in where the school carries the technical burden, and which risks it is equipped to manage.

The Regulatory Shift: Meeting WCAG 2.1 Standards by 2025

The European Accessibility Act has changed the language of digital procurement across Europe, but its scope needs to be read carefully. It applies to specified products and services, including certain consumer-facing digital services, rather than to every digital product or service used by an EU resident. A chatbot embedded in a public school's infrastructure is not automatically covered simply because it uses artificial intelligence or is available online.

That does not make accessibility optional. Schools may still be bound by other public-sector accessibility duties, national rules, contractual requirements, or procurement standards. In practice, a tender may require WCAG 2.1 Level AA conformance even where the EAA itself is not the legal instrument doing the work. A school may also decide that the same standard should govern internal tools because teachers, administrators, parents, and students all rely on the digital environment.

The result is a procurement question with two layers:

• Is the specific service within the scope of the EAA or another applicable accessibility rule?
• Regardless of the minimum legal scope, what accessibility standard should the school require from a system used by its community?

WCAG 2.1 Level AA remains a common reference point for answering the second question. Its success criteria cover perceivable content, operable interfaces, understandable information, and robust compatibility with assistive technologies. For a chatbot, that means more than making the text visually readable.

A usable school chatbot may need to support screen readers, keyboard-only navigation, text resizing, sufficient colour contrast, visible focus indicators, predictable movement of the conversation, and clear error messages. Dynamic messages must be announced in a way that does not overwhelm or confuse a screen-reader user. Buttons need meaningful names. Time limits should not force a student to lose an answer halfway through a support conversation. If the bot presents images, documents, or links, those elements need accessible alternatives and a logical reading order.

The same applies to the material surrounding the chatbot. A technically accessible conversation window cannot compensate for an inaccessible login form, an unlabeled upload control, a PDF that a screen reader cannot parse, or a support process that ends with an unusable booking page. Accessibility belongs to the complete user journey, not only to the component that carries the AI label.

Nor does a failure of one WCAG criterion automatically create a fixed penalty. Enforcement is generally shaped by the applicable law, the seriousness and persistence of the noncompliance, the organisation's response, and the remedies available in the relevant jurisdiction. Authorities may require corrective action, restrict a service, or apply sanctions under national rules. The familiar figure of up to 30,000 euros should therefore not be presented as an automatic charge attached to every isolated accessibility defect.

The legal question is not whether a chatbot sounds modern. It is whether the service, the user journey, and the institution’s response can withstand scrutiny.

For procurement officers, the practical shift is still substantial. Accessibility can no longer be treated as a statement in a vendor brochure. A credible tender should ask for the product's accessibility architecture, known limitations, testing history, remediation process, and responsibilities for third-party components. It should also specify what happens when a future update changes the interface or the underlying model.

Conformance is a process, not a product label

A supplier's claim that a chatbot is “WCAG compliant” is not enough to establish conformance. WCAG conformance is assessed against particular content, functionality, and success criteria. A service can perform well in one environment and fail in another because of the browser, assistive technology, language, authentication method, or integration around it.

Schools should expect a combination of methods:

• automated scanning for detectable issues such as missing labels, contrast problems, and some structural errors;
• manual keyboard testing across the full conversation flow;
• testing with screen readers and other assistive technologies;
• checks of focus order, status messages, time limits, error recovery, and zoom behaviour;
• testing of real tasks, such as requesting learning support, uploading a document, or finding a policy;
• involvement of disabled users or accessibility specialists before deployment and after major changes.

An accessibility statement and an audit report are useful evidence, but they are not interchangeable. The statement should explain known limitations and provide a route for feedback. The audit should identify what was tested, in which environment, and with what result. A school that cannot answer those questions has not transferred responsibility to the vendor; it has simply deferred the risk.

Open-Source Flexibility: Data Sovereignty and Customization in Schools

Open-source AI chatbots for education have moved from experimental demonstrations toward operational use. One German example is AIS.chat, a platform developed for public schools and associated with a deployment model in which institutions can retain greater control over their infrastructure and data. The broader attraction of this approach is not the label “open” by itself. It is the ability to inspect, adapt, and operate the system without making every important decision dependent on a single supplier.

For schools, data sovereignty is a practical issue. A conversation with a chatbot may include a student's name, disability-related information, family circumstances, learning difficulties, or details about a safeguarding concern. Even when a system is intended only to answer routine questions, users do not always distinguish between a general information service and a confidential support channel. The architecture must therefore reflect the sensitivity of the setting.

An on-premises or private-cloud deployment can give an institution more control over where data is stored, how long it is retained, and which systems can access it. It does not automatically make the processing lawful or secure. The school still needs clear retention rules, access controls, logging, incident response, model governance, and a decision about whether sensitive conversations should be stored at all. A self-hosted system can reduce dependence on a vendor's infrastructure while increasing the institution's own responsibilities.

Customization is the other major advantage. Open code can be modified to fit an existing learning management system, identity provider, student information system, or accessibility support process. A school serving multilingual families may want the bot to explain enrolment and support procedures in several languages. A district with a particular screen-reader user base may need to alter the interface and test it against the assistive technologies used locally. A school supporting students with cognitive disabilities may prefer shorter exchanges, explicit confirmation steps, reduced visual movement, or a consistent route to a human adviser.

These are not cosmetic preferences. A chatbot that is accessible in a generic demonstration may become difficult to use when the school adds authentication, file uploads, translated content, or a hand-off to a teacher. Open-source access makes it possible to address those issues directly instead of waiting for a vendor's product roadmap.

The freedom also has limits. The Open Source Initiative's definition of open-source AI gives useful attention to the freedoms to use, study, modify, and share, but the practical openness of a system depends on its components. The interface may be open while the underlying model is not. A model may be replaceable while the training data, hosting environment, or security tooling remains controlled by another party. Schools need to examine the whole stack rather than assume that a public code repository guarantees independence.

There is a similar danger in treating customization as accessibility. A development team can add semantic HTML, ARIA attributes, alternative text, translations, and keyboard support, yet still produce a service that fails real users. Accessibility depends on how those elements work together. Automatically generated alt text may be incomplete or misleading. A translation may change the meaning of an instruction. An ARIA label may help a screen reader while making the visual interface less clear for another user. Dynamic chat updates may be technically announced but practically exhausting.

Open-source systems therefore require an operating model, not only a technical installation. Someone must review changes, monitor dependencies, update the model, respond to security issues, repeat accessibility tests, and maintain documentation. If the school lacks that capacity, the apparent savings on licensing can become a permanent staffing obligation.

Proprietary Solutions: Vendor Support and Rapid Deployment Models

Proprietary AI chatbots enter procurement with a different proposition: the school buys not only software, but also a defined support relationship. Vendors may provide implementation assistance, accessibility documentation, hosting, security updates, integration services, and a contractual route for reporting defects. For a district without dedicated accessibility engineers, that package can be more valuable than access to source code.

Deployment can also be faster. A mature product may already include authentication, analytics, content management, escalation to a human adviser, and integrations with common education systems. A vendor can offer a tested configuration for a standard use case while the school's technical team concentrates on content, staff training, and safeguarding procedures.

That speed should not be confused with proof of accessibility. “Designed for accessibility” is a starting claim, not an audit result. A vendor's documentation may describe the core product while omitting the school-specific configuration. The problem may appear only after a local administrator adds a widget, changes the colour scheme, embeds the chatbot in a learning management system, or connects it to a third-party translation service.

Procurement should make the vendor's responsibilities concrete. Useful contractual questions include:

• Which parts of the chatbot and its surrounding interface were tested against WCAG 2.1 Level AA?
• Were tests performed with keyboard navigation, screen readers, zoom, text reflow, and high-contrast settings?
• How are dynamic responses and error messages exposed to assistive technologies?
• What is the process for reporting an accessibility defect, and what remediation times are realistic?
• Does a model, interface, or third-party dependency change without advance notice?
• Who pays for testing after a substantial update?
• Can the school export conversation data, configuration, and knowledge-base content if it changes supplier?
• Where is data processed, and can the vendor use student interactions for model training?
• What happens when the chatbot cannot answer safely or confidently?

Vendor accountability is meaningful only when the contract defines it. A general promise to “follow accessibility best practice” gives the school little leverage when a critical support flow fails. A service-level agreement, change-notification process, audit access, and clear division of responsibilities are more useful than a glossy compliance page.

The proprietary model also creates dependency. Licensing may scale by users, seats, messages, or usage volume. Costs can rise as adoption expands, while the school's knowledge base and workflows become increasingly tailored to the platform. If the vendor changes its pricing, discontinues a feature, or limits access to an integration, switching becomes a strategic project rather than a simple technical replacement.

Data residency is another area that needs precision. Vendor hosting is not necessarily incompatible with public-sector use, and self-hosting is not automatically safer. The relevant questions are where data is processed, which subcontractors are involved, what security controls exist, how deletion works, and whether the school can enforce its own retention policy. A vendor with strong controls may offer better operational security than an under-resourced self-hosted installation. The institution must assess the actual arrangement, not rely on the category.

The decision is about capacity as much as technology

The open-versus-proprietary debate often becomes ideological because the two options represent different institutional values. In practice, the more useful question is where the school has capacity.

The table does not produce a universal winner. It shows where the burden moves. Open-source software shifts more responsibility toward the school but can preserve strategic control. Proprietary software shifts more operational work toward a vendor but makes the institution dependent on the vendor's priorities, timetable, and evidence.

Real-World Impact: From Administrative Relief to Inclusive Student Support

The case for accessible education chatbots is not limited to avoiding regulatory trouble. The strongest argument is that they can remove friction from ordinary interactions that already exclude some students and families.

The Aalborg University research reported administrative time savings of up to 30%. That figure should not be treated as a guaranteed result for every school. It indicates the potential value of automating repetitive questions and routing tasks, particularly where staff spend time repeating information about timetables, forms, deadlines, policies, and support pathways. The quality of the knowledge base, the clarity of escalation rules, and the staff's ability to correct mistakes will determine whether those savings appear in practice.

Administrative relief can have an accessibility effect of its own. When teachers spend less time answering routine questions, they may have more time for individual explanations, meetings, and adjustments. But automation should not become an excuse to reduce human support. A student who cannot complete a form, understand a generated answer, or explain a complex situation needs an easy route to a person.

The Open University in the UK deployed a chatbot named Taylor as part of the ADMINS project. Its role was specific: providing a conversational route through which students could disclose disabilities and access support services. That use case illustrates why interface accessibility and service accessibility are connected but distinct. A chat window may be easier than a long form for some students, especially when the student is unsure which category describes their needs. Yet the conversation must still protect privacy, explain what will happen to the information, and allow the student to correct or withdraw an answer.

The chatbot should also avoid implying that disclosure automatically produces support. A good service makes the next step visible: whether a staff member will review the request, whether evidence is needed, and how long a response may take. Otherwise, the system can make access look easier while leaving the underlying process unchanged.

AccessiLearnAI, an accessibility-first e-learning platform published in August 2025, is described as combining semantic HTML5, ARIA standards, large-language-model functions, automatic alt-text generation, and real-time translation. Those features point in the right direction, but they should be understood as design choices rather than conformance proof. Semantic structure can improve navigation. ARIA can expose relationships that are otherwise hidden. Translation can make content available to more learners. None of these, alone or together, establishes WCAG 2.1 Level AA conformance without testing.

The most promising deployments treat the chatbot as one layer in a broader support system. They define what the bot is allowed to answer, identify topics that require human intervention, and measure whether students actually complete the intended task. A useful evaluation might examine:

• whether students can find the service without assistance;
• whether screen-reader and keyboard users can complete the same task as other users;
• whether the bot understands varied wording, spelling, and language backgrounds;
• whether students know when they are speaking to an automated system;
• whether sensitive requests are routed safely;
• whether staff can review, correct, and update answers;
• whether students return to a human channel when the bot fails.

That last point is crucial. A chatbot that handles routine requests well but makes it difficult to reach a person is not an accessible service. It is an accessible-looking barrier.

Open-source code buys sovereignty. Proprietary code buys time. Neither buys accessibility without evidence.

Navigating the Future of Accessible EdTech Infrastructure

WCAG 3.0 remains part of the longer-term conversation. It is still a developing standard, and its eventual relationship with European law and public procurement should not be treated as settled. Schools planning a multi-year deployment should nevertheless assume that accessibility expectations will evolve, even if the legal timetable is uncertain.

The sensible response is not to wait for the next standard. It is to build an infrastructure that can be tested and changed. That means keeping the chatbot's content separate from its interface where possible, documenting integrations, preserving exportable data, and avoiding design choices that make every update a full reconstruction. It also means budgeting for recurring accessibility work rather than treating the initial audit as a certificate that lasts indefinitely.

Three questions deserve attention during the life of the system.

First, can the school identify exactly which service is being provided and which obligations apply to it? This keeps legal analysis separate from broad claims about every digital tool in a public institution. It also makes procurement language more precise.

Second, can the school test the complete user journey after changes? A new model, a new login provider, a redesigned interface, or a changed escalation workflow can introduce barriers even when the chatbot engine itself is unchanged.

Third, can the institution preserve a meaningful choice of supplier? Exportable content, documented APIs, clear data-retention controls, and modular integrations reduce the cost of changing direction. These are not abstract technical preferences. They determine whether a school can respond when a vendor's accessibility performance declines or when an open-source maintenance team can no longer support the deployment.

The public sector opportunities around education technology accessibility AI are therefore broader than the initial purchase of a chatbot. They include accessibility testing, secure hosting, multilingual content design, assistive-technology research, staff training, procurement support, and independent auditing. Public schools need accessible edtech chatbots, but they also need the surrounding expertise to keep those systems accessible after launch.

A school with a strong IT team, established privacy controls, and clear data-sovereignty requirements may find open source more compatible with its operations. A school without dedicated technical staff and with a pressing deployment timetable may find a proprietary platform more defensible. A hybrid arrangement may be more realistic than either extreme: a vendor-supported interface connected to institution-controlled data, or an open-source front end paired with a managed model and contracted accessibility testing.

The important point is not to present either model as compliant by construction. Open-source flexibility can support a strong accessibility programme, but it cannot replace one. Proprietary support can accelerate remediation, but it cannot make local testing unnecessary. WCAG 2.1 Level AA is a useful floor for design and procurement; conformance is demonstrated through evaluation, correction, and continued review.

The schools most likely to benefit are not those that choose the most fashionable architecture. They are those that know what the chatbot is for, what it must never handle alone, who is responsible when it fails, and how a student can still reach a person. Accessibility becomes durable when it is treated as part of infrastructure rather than as a feature attached to an AI product at the end.