Improve accessibility and resolve website audit findings

This commit is contained in:
git
2026-07-27 10:55:15 +10:00
parent b55d5a92ea
commit 9169084d57
12 changed files with 201 additions and 69 deletions
+52 -18
View File
@@ -2,15 +2,7 @@
## Project purpose
This repository contains the public website for the Napper application ecosystem.
The site includes:
- the main `napper.au` landing site;
- the Hudra product site;
- the Lildra product site;
- the Pendra product site;
- shared legal, privacy, support and ecosystem content.
This repository contains the public website for the Napper application ecosystem. It includes the main `napper.au` landing site, the Hudra product site, and shared legal, privacy, support and ecosystem content. Lildra and Pendra product pages are planned but do not yet exist.
## Source of truth
@@ -22,6 +14,56 @@ When an important architectural, deployment, naming or development decision is m
2. update this file when the guidance affects AI contributors;
3. avoid relying on undocumented conversational context.
## Product distinction
- Hudra is primarily a presentation and slide-viewing system that turns complete QLearn lesson pages into a classroom presentation experience. Do not describe Hudra as a general-purpose editor.
- Lildra is the product focused on removing the surrounding QLearn interface and showing lesson-page content cleanly.
- Pendra is planned as a simpler path for bringing completed presentation slides into QLearn.
Keep product wording within these boundaries and do not reuse Lildra's clutter-removal positioning as Hudra's primary message.
## Current architecture
The site is a dependency-free static site using HTML, CSS and small browser JavaScript files. Do not introduce a framework, package manager, build system or templating engine without an explicit architectural decision.
```text
/
├── index.html
├── css/
│ ├── napper.css
│ ├── hudra.css
│ └── hudra-legal.css
├── js/
│ ├── napper.js
│ └── hudra.js
├── img/
└── hudra/
├── index.html
├── support/index.html
├── privacy/index.html
└── terms/index.html
```
The Hudra header, footer and foundational styling are currently repeated. Establish shared-component and shared-style conventions before duplicating Hudra's structure for Lildra or Pendra. Do not introduce those abstractions incidentally during an unrelated focused change.
## Deployment assumptions
- The repository is `napper/site` and is deployed to `napper.au`.
- A push to `main` triggers automatic deployment.
- Gitea sends a signed webhook to the CloudPanel server.
- `dploy` creates a release and switches the site's `current` symlink.
- CloudPanel serves `/home/napper/htdocs/napper.au/current`.
- The production server supports directory URLs such as `/hudra/privacy`, resolving them to the relevant `index.html`.
- Pages and assets use root-relative paths and assume deployment at the domain root.
Do not expose webhook secrets, credentials or other server-specific private data.
## Canonical external locations
- QLearn: `https://qlearn.eq.edu.au`
- Gitea organisation: `https://git.napper.au/napper`
- Hudra releases: `https://git.napper.au/napper/hudra/releases`
## Working principles
- Keep the site simple and maintainable.
@@ -30,8 +72,6 @@ When an important architectural, deployment, naming or development decision is m
- Preserve accessibility, responsive design and fast page loads.
- Reuse shared styles and components where practical.
- Keep each application page focused on what the application does.
- Do not describe Hudra as a general-purpose editor.
- Treat Hudra primarily as a presentation and slide-viewing system for QLearn.
- Do not expose secrets, credentials or server-specific private data.
- Keep deployment configuration documented and reproducible.
@@ -41,10 +81,4 @@ When an important architectural, deployment, naming or development decision is m
2. Make focused changes.
3. Test locally where possible.
4. Update documentation when behaviour or structure changes.
5. Commit using a clear, descriptive message.
## Project structure
The final structure will be documented after the existing website is imported and audited.
Do not invent a new architecture before inspecting the existing site.
5. Commit using a clear, descriptive message when a commit is requested.