Improve accessibility and resolve website audit findings
This commit is contained in:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user