The author is updating an introductory web development course to include more focus on progressive enhancement, seeking advice and resources to improve accessibility and best practices.
<p>For $REASONS, I ended up in control (probably temporarily) of a rather introductory «Web Development» course with a bit of HTML/CSS/JS/Docker that I plan (and promised) to keep in a mostly recognisable shape.</p>
<p>I do want to add more reminders that progressive enhancement is good, though; and I ask for advice on good points/references.</p>
<hr>
<p>I am going to keep NodeJS backend assumption, so any JavaScript-the-language feature can be demonstrated on backend. So just learning to use JS in general is not as much of an excuse for silly things in-browser.</p>
<p>My plan includes telling more than before about (and probably giving links to):</p>
<ul>
<li>
<a href="https://madcampos.dev/blog/2026/07/accessibility-from-scratch/" rel="ugc">https://madcampos.dev/blog/2026/07/accessibility-from-scratch/</a> — usability and accessibility benefits of proper HTML</li>
<li>
<a href="https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/" rel="ugc">https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/</a> — accessibility in wider sense of things that work on pure and minimal HTML</li>
<li>
<a href="https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies/defaultjavascriptjitsetting" rel="ugc">https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies/defaultjavascriptjitsetting</a> — MS Edge having a secure mode where JS JIT is off (and JS is slow)</li>
<li>
<a href="https://developer.chrome.com/blog/timer-throttling-in-chrome-88/" rel="ugc">https://developer.chrome.com/blog/timer-throttling-in-chrome-88/</a> — even Google admits that JS is bad for battery life…</li>
<li>
<a href="https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html" rel="ugc">https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html</a> — as a reminder not to trust too much work done on frontend</li>
<li>
<a href="https://github.com/lwthiker/curl-impersonate" rel="ugc">https://github.com/lwthiker/curl-impersonate</a> — for general trolling (more seriously, to remind how many sites <em>pretend</em> to need JS but give Blink-based browsers fully sufficient HTML, then try to make it hard for any other browsers, and often fail)</li>
</ul>
<p>And I guess general stressing that document, form, and application are three different things.</p>
<p>I would be grateful for suggestions of other/same-but-well-made points towards progressive enhancement, not spending extra effort to break accessibility, etc. Ideally I hope to cover what has normally been covered previously, but with a viewpoint shift towards healthy approaches. Active improvements to accessibility are probably beyond what would fit and beyond what I can explain well.</p>
# WebDev intro course: what small changes towards progressive enhancement?
Source: [https://lobste.rs/s/nr3ucr/webdev_intro_course_what_small_changes](https://lobste.rs/s/nr3ucr/webdev_intro_course_what_small_changes)
For $REASONS, I ended up in control \(probably temporarily\) of a rather introductory «Web Development» course with a bit of HTML/CSS/JS/Docker that I plan \(and promised\) to keep in a mostly recognisable shape\.
I do want to add more reminders that progressive enhancement is good, though; and I ask for advice on good points/references\.
---
I am going to keep NodeJS backend assumption, so any JavaScript\-the\-language feature can be demonstrated on backend\. So just learning to use JS in general is not as much of an excuse for silly things in\-browser\.
My plan includes telling more than before about \(and probably giving links to\):
- [https://madcampos\.dev/blog/2026/07/accessibility\-from\-scratch/](https://madcampos.dev/blog/2026/07/accessibility-from-scratch/)— usability and accessibility benefits of proper HTML
- [https://shkspr\.mobi/blog/2021/01/the\-unreasonable\-effectiveness\-of\-simple\-html/](https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/)— accessibility in wider sense of things that work on pure and minimal HTML
- [https://learn\.microsoft\.com/en\-us/deployedge/microsoft\-edge\-policies/defaultjavascriptjitsetting](https://learn.microsoft.com/en-us/deployedge/microsoft-edge-policies/defaultjavascriptjitsetting)— MS Edge having a secure mode where JS JIT is off \(and JS is slow\)
- [https://developer\.chrome\.com/blog/timer\-throttling\-in\-chrome\-88/](https://developer.chrome.com/blog/timer-throttling-in-chrome-88/)— even Google admits that JS is bad for battery life…
- [https://cheatsheetseries\.owasp\.org/cheatsheets/Input\_Validation\_Cheat\_Sheet\.html](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html)— as a reminder not to trust too much work done on frontend
- [https://github\.com/lwthiker/curl\-impersonate](https://github.com/lwthiker/curl-impersonate)— for general trolling \(more seriously, to remind how many sites*pretend*to need JS but give Blink\-based browsers fully sufficient HTML, then try to make it hard for any other browsers, and often fail\)
And I guess general stressing that document, form, and application are three different things\.
I would be grateful for suggestions of other/same\-but\-well\-made points towards progressive enhancement, not spending extra effort to break accessibility, etc\. Ideally I hope to cover what has normally been covered previously, but with a viewpoint shift towards healthy approaches\. Active improvements to accessibility are probably beyond what would fit and beyond what I can explain well\.
Ariel Salminen introduces Elena, a 2.6kB open-source library for building Progressive Web Components that render HTML and CSS without JavaScript and enhance progressively. The article explains the design philosophy and taxonomy behind the approach.
HTMLcat is a resource offering small, native web tricks for HTML, CSS, and JavaScript, including examples and notes on browser support and accessibility.
A comprehensive checklist for building modern websites covering HTML fundamentals, SEO, accessibility, and more, sourced from the Website Specification.
A personal blog post by a non-web developer discusses the unavoidable bad parts of CSS, including layout challenges, browser defaults, and wrapper overuse, while highlighting a learnable subset for simple tasks.
The author reflects on migrating from Tailwind CSS to vanilla CSS with semantic HTML, sharing insights on structuring CSS using systems like resets, components, and utility classes learned from Tailwind.