Build, share, and improve WCAG-compliant Open Educational Resources with Python!

OER-Forge is an open source Python toolkit for building, organizing, and publishing accessible Open Educational Resources (OERs). It helps authors create sites and documents that meet WCAG standards, with a focus on clean code, extensibility, and fun!

• Accessible by design: All templates and outputs aim for WCAG compliance.
• Database-driven navigation: Section indices, menus, and hierarchy are managed in SQLite for robust, extensible site structure.
• Multi-format export: Markdown, DOCX, PDF, LaTeX, and more.
• Built for maintainers: Clean Code, SOLID principles, and a growing suite of tests.
• Fun to hack: Professional, but not boring. ☕️❤️

For full documentation and usage, see the main OER-Forge README.

1. Clone the repo:

   git clone https://github.com/OER-Forge/OER-Forge.git
   cd OER-Forge

2. Install dependencies:

   pip install -r requirements.txt

3. Build the site:

   python build.py

4. View your site: Open build/index.html in your browser.

• Section indices & navigation: DB-driven, supports arbitrary hierarchy, top-level and nested menus.
• Accessibility: ARIA labels, alt text, color contrast, keyboard navigation.
• Download options: Export pages in multiple formats (PDF, DOCX, TXT, etc.).
• Dark mode: Toggle theme for better readability (issue #3).
• Inline figures: Markdown images with alt text for accessibility (issue #4).
• Extensible templates: Jinja2-based, easy to customize.
• Robust build system: Automated, logs to log/ for debugging.

• Section index content missing
• Verify and improve handling of grandchildren in navigation
• Dark mode download button visibility
• Inline figures and alt text
• Review verify.py for efficiency

See all issues and contribute: GitHub Issues

We welcome your feedback, suggestions, and pull requests! Check out good first issues or help wanted to get started.

• Report a bug: File an issue
• Request a feature: File an enhancement
• Ask a question: Open a question

Content and code are licensed under CC BY-NC-SA 4.0.

Made with ☕️ and ❤️ for students and educators everywhere. | Built with OER-Forge

Last updated: 2025-07-18

• Run python make.py to build the site and generate all outputs.
• Confirm all Markdown (.md) files are converted to all requested formats (PDF, DOCX, LaTeX, EPUB, TXT, etc.).
• Check that images in Markdown files appear in DOCX, PDF, and LaTeX outputs.
• Ensure all outputs are placed in the correct section-local directories (next to index.html and in files/ as needed).
• Remove any duplicate or stub converter functions in convert.py.
• Clean up debug prints and stub counters in production code.

• Run verify.py on all generated HTML files.
• Log accessibility results in the database.
• Inject accessibility badges/labels into HTML pages.
• Generate and link per-page accessibility reports.
• Summarize accessibility results in the admin/build report.

• Implement or update build/admin/index.html to summarize all build and accessibility results.
• Include links to all outputs and per-page accessibility reports.
• Ensure the admin report is accessible and easy to scan.

• Remove obsolete outputs from build/ to match the current export plan.
• Ensure repeated builds do not leave stale files or DB records.
• Log all errors and reasons for failed conversions or checks (do not block build).

• Add CLI options for --dry-run, --force, and --report in make.py.
• Ensure CLI is intuitive and safe (no destructive actions in dry-run mode).
• Print build and accessibility summaries to console and write to admin report.

• Update README and in-code documentation to reflect the current pipeline, config, and output structure.
• Document all new database fields and config options for future maintainers.
• Ensure the system is extensible for new export types, accessibility tools, or reporting features.

• Test all conversions and accessibility checks with real content, including edge cases (images, custom paths, forced conversions).
• Move or refactor sections and confirm all internal links and assets remain valid.
• Run repeated builds with config changes to ensure robustness.

Tip: Work through this checklist after every major refactor or before a release to ensure OER-Forge remains robust, accessible, and maintainable.

Filed automatically by GitHub Copilot based on user request.