There’s a quiet compliance problem in almost every enterprise file sharing deployment. Images get uploaded without alt text. Not because anyone thinks accessibility is unimportant. Because writing alt text manually is slow, nobody enforces it, and „we’ll do it later“ becomes „we never did it.“<\/p>\n
WCAG 2.2<\/a> requires descriptive alt text for all non-decorative images. EN 301 549<\/a> \u2014 the European accessibility standard for public sector ICT \u2014 mandates it. Organisations deploying oCIS in schools, government, and research institutions operate under these requirements. And until today, oCIS had no way to help meet them.<\/p>\n web-app-ai-image-alt-text-sidebar merged this morning. PR #467<\/a>. 16 commits. Lukas Hirt<\/a>.<\/p>\n Select any image file in oCIS: .jpg, .png, .webp, .gif. An „Alt Text“ tab appears in the sidebar. Click it. The extension downloads the image via WebDAV, base64-encodes it, and sends it to your configured vision-capable LLM. The result appears in an editable text field. Copy it, edit it, or save it directly back to the file.<\/p>\n Generated alt text is persisted to the file as a WebDAV<\/a> custom property: urn:oc:ai:alt-text:text. Written back via PROPPATCH. Retrieved on the next panel open via PROPFIND. The alt text survives the session, survives panel close, and will be ready when screen readers and search indexers learn to look for that property.<\/p>\n Three states based on LLM configuration:<\/p>\n The extension applies a 4 MB image size limit before encoding and sending the payload. Anything larger triggers a user-facing message. That guard is there because most vision LLMs have context window limits \u2014 a 12 MB product photo sent to a small local model will either fail silently or produce degraded output. The guard surfaces the limit explicitly.<\/p>\n Copy, Regenerate, and Save are three different buttons for three different use cases: put the alt text somewhere else, generate again if the first result missed the mark, or store it on the file.<\/p>\n The EU Accessibility Act<\/a> entered into force in 2025. The Web Accessibility Directive<\/a> has applied to public sector bodies since 2018. EN 301 549 is the harmonised standard. For any organisation deploying oCIS in a public sector context \u2014 one existing organisation using ownCloud alone serves millions of students \u2014 WCAG compliance isn’t optional.<\/p>\n Missing alt text is one of the most commonly flagged WCAG failures<\/a> in automated audits. An extension that generates a credible first draft in seconds, lets the user edit it, and writes it back to the file in a persistent format is a meaningful compliance tool, not just a convenience feature.<\/p>\n Search engine indexing of the stored WebDAV property requires a future oCIS server-side change \u2014 explicitly noted as out of scope in the PR. The property is being written today so it will be ready when server-side support arrives.<\/p>\n The PR description itself was AI-generated, marked explicitly at the top: „AI-generated \u00b7 OSPO-46 \u00b7 Gate: \u2705 1.00.“ This is the AI-Assisted Contribution Policy<\/a> in practice \u2014 not just on the code but on the entire pull request workflow.<\/p>\n The extension was generated using extctl \u2014 a tool Lukas built<\/a> for scaffolding oCIS web extensions. Lukas isn’t just writing extensions. He’s building tooling that makes writing extensions faster. The OSPO-46 Jira ticket tracks this as part of a deliberate programme. Gate score: 1.00.<\/p>\nWhat It Does<\/h3>\n
\n
A 4 MB Guard and What It Tells You About the Engineering<\/h3>\n
WCAG, EN 301 549, and Why This Matters for Public Sector<\/h3>\n
The PR Was AI-Generated. So Was the Tooling.<\/h3>\n
Five PRs in Eight Days<\/h3>\n