At work I build javascript laden behemoth websites. I'm working on a custom RSS reader and I'm really looking forward to building something as lightweight as I can!
At work I build javascript laden behemoth websites. I'm working on a custom RSS reader and I'm really looking forward to building something as lightweight as I can!
I got my site to work without JavaScript the other day. I'm also learning about accessibility. I'm finding the web to be incredibly complicated so it's nice to simplify things a bit.
I got my site to work without JavaScript the other day. I'm also learning about accessibility. I'm finding the web to be incredibly complicated so it's nice to simplify things a bit.
You are right, it is not only about JavaScript. We need to learn about accessibility and make the site useable for visual impaired people. I will read about that too.
You are right, it is not only about JavaScript.
We need to learn about accessibility and make the site useable for visual impaired people.
I think it's useful to really emphasize that "no-javascript friendly sites" doesn't need to mean "no javascript". It just means your site needs to have its baseline functionality work without...
I think it's useful to really emphasize that "no-javascript friendly sites" doesn't need to mean "no javascript". It just means your site needs to have its baseline functionality work without javascript running in the user's browser; it's fine to use javascript to provide extra functionality, or to make the functionality present in the HTML/CSS better. This is the principle of progressive enhancement.
The principle of progressive enhancement isn't just about supporting the few users with javascript disabled. The principle means your site will also work before the javascript is loaded, and will continue to work if anything goes wrong with the javascript. Your site will become readable faster to users on slow or spotty connections, and if there are any problems with your javascript (like you accidentally relied on a very new feature that's not commonly supported in browsers, you didn't use a polyfill, and you only tested in one browser, and then a user visits with an incompatible browser), then things still mostly work.
If you make a site built using React, you should do server-side rendering so that the each page's HTML contains the initial render of the page. The easiest way to do this is to use Next.js or Gatsby. You make your pages out of normal React components. The gotcha is that your React components won't ever have their useEffect/componentDidMount callbacks or any of their event handlers fire for users who don't load the page javascript. As long as your React components put out useful HTML in their initial render, as is good practice anyway, you should be fine.
I agree. One common JS library for example is called HoverIntent, and it's smart about not closing the menu just because you accidentally moved the mouse off of it for a tenth of a second. For...
I agree. One common JS library for example is called HoverIntent, and it's smart about not closing the menu just because you accidentally moved the mouse off of it for a tenth of a second. For people who have trouble controlling their mouse, this can make hover menus substantially easier to use.
I know a lot of people assume that JS == inaccessible, but that's not the case. Screen readers and similar tools do work with JS today.
Looks really nice, I'd love to see a demo somewhere. (And it's not that I don't believe you, it's that it's unlikely to be possible in css to be truly accessible with regards to the accessibility...
Looks really nice, I'd love to see a demo somewhere.
(And it's not that I don't believe you, it's that it's unlikely to be possible in css to be truly accessible with regards to the accessibility features mentioned in my other post)
I'm currently making a docs website, I can give you a link to it when it's ready. (Should be soon, the main thing was the menu, the rest is just markdown pages.) tbh the only thing I couldn't do...
I'm currently making a docs website, I can give you a link to it when it's ready. (Should be soon, the main thing was the menu, the rest is just markdown pages.)
tbh the only thing I couldn't do with css only is keyboard trapping. When you're in that mobile version, you could tab out and reach the rest of the page. Haven't found a way to solve that yet. Most likely I'll just solve that with JavaScript and consider it acceptable.
Feels quite smooth. I like it. As a tip, it would be more screen reader-friendly If you used <li> in there as well. Right now it'll be read as assorted links on a page, rather than a single list...
Feels quite smooth. I like it.
As a tip, it would be more screen reader-friendly If you used <li> in there as well. Right now it'll be read as assorted links on a page, rather than a single list of navigation items.
I'm seeing a lot of conflicting information about doing that. Apparently screen readers will say a lot of useless information when a nav contains a list of links. I'm basing my work on Tailwind UI...
I'm seeing a lot of conflicting information about doing that. Apparently screen readers will say a lot of useless information when a nav contains a list of links. I'm basing my work on Tailwind UI which doesn't use that, you can see an example here: https://tailwindui.com/preview (check the code on the first one for example "Dark nav with white page header").
But I just tested in the Lynx browser and this is how it looks:
Screen readers can be configured to be more or less verbose. I'm not sure why Tailwinds opted not to use them here, but in my opinion it's best to give the client as much context as possible. They...
Screen readers can be configured to be more or less verbose. I'm not sure why Tailwinds opted not to use them here, but in my opinion it's best to give the client as much context as possible. They can decide what to do with it.
I've never used Lynx myself. I'd be curious to see how it handles newer layout tools like flexbox and grid.
How so? What is missing from a CSS based menu that JavaScript would solve? I can only really think of not supporting older browsers (if the CSS uses some fancy new features), but apart from that...
How so? What is missing from a CSS based menu that JavaScript would solve? I can only really think of not supporting older browsers (if the CSS uses some fancy new features), but apart from that (from a accessibility perspective) I've a hard time coming up with something concrete.
@wes already gave an example; to add to it, there's a lot of other tricks high quality menu libraries will implement to detect "intent". For example, let's say you're over a menu that looks like...
@wes already gave an example; to add to it, there's a lot of other tricks high quality menu libraries will implement to detect "intent". For example, let's say you're over a menu that looks like this:
Top 1 >
Top 2 >
And you're over Top 1 so it looks like this:
Top 1 >
Leaf 1
Leaf 2
Leaf 3
Top 2 >
You want to click "Leaf 2" but in doing so, you briefly hover over Top 2. It won't immediately register intent and will let you click Leaf 2 without updating the submenus.
Some of the C++ libraries even look at the direction your mouse is moving and its velocity.
Menus should also be accessible with focus-based keyboard navigation, which most CSS-only menus are not or cannot be.
DOM-wise, menus should have role and aria attributes to identify them and tell whether or not they're expanded and what they expand into. All of this is very well supported to give screen readers a good navigation experience.
The issue of immediately switching between menu items when hovering changed can be resolved with a simple transition-delay. I typed up a brief sample: <!DOCTYPE hmtl> <html> <body> <style> nav {...
The issue of immediately switching between menu items when hovering changed can be resolved with a simple transition-delay. I typed up a brief sample:
The keyboard navigation is much simpler to resolve if each menu item contains an anchor tag. That way navigation can be done with the tab key. As for the aria attributes they are supposed to be used for rich internet applications and besides if you use nav and menu I think defining the roles is superfluous (they are already defined for those elements I think, but not 100% sure).
I think CSS animations do help the issue, but aren't quite as good at determining intent as a Javascript solution would be. This is definitely helpful too, but keep in mind that tabbing is only...
I think CSS animations do help the issue, but aren't quite as good at determining intent as a Javascript solution would be.
The keyboard navigation is much simpler to resolve if each menu item contains an anchor tag. That way navigation can be done with the tab key
This is definitely helpful too, but keep in mind that tabbing is only one method of navigation. Ideally you would cover all bases for accessibility.
For instance, sighted users who navigate via keyboard will require visual feedback to better understand menu context. Just seeing the link target doesn't provide enough information about site hierarchy, for example.
Screen readers can also navigate from other approaches than just tabbing, such as jumping to specific elements. While many screen reader users operate from sound alone, some also retain limited visibility and can also use that extra visual information from seeing menus open. I don't believe that is possible in your example above.
You are right, capturing the intent of the user based on dynamic behaviour would be infeasible with CSS. Using the delay trick gets you most of the benefits, but I sure you could make something...
I think CSS animations do help the issue, but aren't quite as good at determining intent as a Javascript solution would be.
You are right, capturing the intent of the user based on dynamic behaviour would be infeasible with CSS. Using the delay trick gets you most of the benefits, but I sure you could make something even better using js. OTOH using the CSS approach would allow for progressive enhancement whereas using the js option wouldn't.
I'm going to see if using the :focus selector could be used to enable the visual feedback on keyboard navigation :) fun challenge
Just a quick follow up I managed to get the menu working with keyboard navigation (tabbing only no fancy arrow key nav, but still usable) by includin an anchor tag (which you'd probably have...
Just a quick follow up I managed to get the menu working with keyboard navigation (tabbing only no fancy arrow key nav, but still usable) by includin an anchor tag (which you'd probably have either way). Then complementing the hover selector with a menuitem menu:focus-within that also sets the max-height and you are all good. I believe this approach would also work with nested menus. If the :has() pseudoselector gets widespread adoption you could get even fancier.
So in essence at this point in time, if you want a simple and accessible drop-down menu, there is no reason to reach for JS.
I think I inadvertently bash.org'd you into making your menu more accessible. :) I'm glad you found some nice solutions - sounds like a win/win for everyone involved! http://www.bash.org/?152037
I think I inadvertently bash.org'd you into making your menu more accessible. :) I'm glad you found some nice solutions - sounds like a win/win for everyone involved!
Thanks, but its actually a Hugo theme that I tweaked the layout of. Hugo - Base16 If you're looking for a simple static website and have found somewhere to host it then Hugo is a wonderful tool,...
Thanks, but its actually a Hugo theme that I tweaked the layout of. Hugo - Base16
If you're looking for a simple static website and have found somewhere to host it then Hugo is a wonderful tool, write your blog entries in markdown and regenerate the site, upload the public folder to you hosting provider and it's all done.
Here's a bone to chew on: Do you really need dropdown menus? They're supposed to be unobtrusive, save visual space, only show up when needed – but they're fuckin' uncomfortable to navigate. Mouse?...
Here's a bone to chew on:
Do you really need dropdown menus?
They're supposed to be unobtrusive, save visual space, only show up when needed – but they're fuckin' uncomfortable to navigate. Mouse? Takes precision of movement, and is famously prone to slipping onto another item. Keyboard? I can't even navigate to yours with [Tab]-ing through the links.
In navigating the Web – and static blogs in particular – I find that most of the time, I'm passively filtering away irrelevant elements. That navigation bar at the top of the page (provided it stays there, and doesn't follow me around as I scroll), that fixed logo in the top-left corner that takes you to the home page, that subheader with tags and categories and what have you... As long as it isn't actively taking up my attention, I won't notice it. My assumption is: most people are the same, 'cause if I can filter out this kind of information (and I usually can't), others don't even know this may be an issue.
The front page of your blog loads in under 7 seconds on simulated slow 3G connection without cache. With most of the heavy stuff cached, it goes under 3 seconds. This is perfectly acceptable. Instead of listing all the kinds of deep division of content you have in your blog, you could simply link to both the "Categories" page and the "Tags" page, and let the user browse on their own.
Granted, it's a half-baked content strategy – it doesn't even take into consideration who your users are and what sort of content they expect from your blog – but it does give you some perspective on how the navigation could be done.
No. I am aware they are imperfect, it was more of a proof of concept. A good portion of the loaded content is Google fonts which I'm keen to remove now after reading other posts on here recently....
Do you really need dropdown menus?
No. I am aware they are imperfect, it was more of a proof of concept.
A good portion of the loaded content is Google fonts which I'm keen to remove now after reading other posts on here recently.
The default template lists all the "Categories" and "Tags" at the bottom of the page.
Yeah, there's a lack of direction because I wasn't sure what direction it would take and wanted to not pigeon-hole myself into writing specific content.
Do you have any good examples of how a small personal blog should be structured? The taxonomy for posts, depth of content, etc.
Your best bet, should you still want to retain the fonts used (they are rather fitting), is self-hosting the fonts. Google allows this by default. If you want to download the fonts to host...
A good portion of the loaded content is Google fonts which I'm keen to remove now after reading other posts on here recently.
Your best bet, should you still want to retain the fonts used (they are rather fitting), is self-hosting the fonts. Google allows this by default. If you want to download the fonts to host yourself, you can use this Web app.
The default template lists all the "Categories" and "Tags" at the bottom of the page.
That's well and good. I assumed that this is what you want your users to find first, given that you've chosen these items for the dropdown. If it were, your best bet would've been providing a clear headline link to those: this would've let users know immediately where to go and what to see.
Do you have any good examples of how a small personal blog should be structured? The taxonomy for posts, depth of content, etc.
Alas, I'm not too keen on thrawling the blogosphere.
The best advice I could give here, provided you want one, is to put forth what you want your visitors – both first-time and regular – to see first. If you use your own terms for much of the stuff, providing link to a dictionary would be meaningful. If you host a small, Twitter-ish list of short posts that don't jive well with your other content, giving the link to that separate Twitter-ish space would help expose it to those who may not see it otherwise.
Make it as easy to get to the good stuff as you can, without bending over backwards. The lower the overhead of maintaining that "LOOKIE HERE" area of the blog, the easier it will be to change later, and trust me: you do not want to make the process of changing stuff even remotely difficult. This is where procrastination, anxiety, and the eventual ruin of your blogging process comes from: the discomfort of moving things around.
Alas yes, the idea was to document stuff for myself to look back at and rediscover how i did things if I ever needed to revisit them. Didn't really work, I just don't have the motivation to type...
Alas yes, the idea was to document stuff for myself to look back at and rediscover how i did things if I ever needed to revisit them. Didn't really work, I just don't have the motivation to type lengthy pieces. I always hated English at school for all the writing and unnecessary (in my mind) embellishment. It's also the reason I don't post on here much, the longer responses that people give with well thought out answers can be intimidating at times.
Shameless plug of my personal blog which I just use a bash script and pandoc to convert markdown to html: https://crdpa.github.io You will see the size of the problem after installing something...
Shameless plug of my personal blog which I just use a bash script and pandoc to convert markdown to html: https://crdpa.github.io
You will see the size of the problem after installing something like NoScript on Firefox. 90% of the websites are unusable with JavaScript turned off, even if it only have text and some images. I constantly have to enable domains so I just gave up and uninstalled the addon.
Not a lot to chew on here, but you gotta start somewhere. You could, make a fashionable, modern-looking slide-out menu with only HTML4 elements and CSS2 selectors. All you need is a checkbox, a...
Not a lot to chew on here, but you gotta start somewhere.
You could, make a fashionable, modern-looking slide-out menu with only HTML4 elements and CSS2 selectors. All you need is a checkbox, a label attached to it, and some form of navigation that precedes the main content on the page.
At work I build javascript laden behemoth websites. I'm working on a custom RSS reader and I'm really looking forward to building something as lightweight as I can!
I got my site to work without JavaScript the other day. I'm also learning about accessibility. I'm finding the web to be incredibly complicated so it's nice to simplify things a bit.
You are right, it is not only about JavaScript.
We need to learn about accessibility and make the site useable for visual impaired people.
I will read about that too.
This is my favorite resource: https://www.w3.org/TR/wai-aria-practices-1.1/.
Thanks.
I think it's useful to really emphasize that "no-javascript friendly sites" doesn't need to mean "no javascript". It just means your site needs to have its baseline functionality work without javascript running in the user's browser; it's fine to use javascript to provide extra functionality, or to make the functionality present in the HTML/CSS better. This is the principle of progressive enhancement.
The principle of progressive enhancement isn't just about supporting the few users with javascript disabled. The principle means your site will also work before the javascript is loaded, and will continue to work if anything goes wrong with the javascript. Your site will become readable faster to users on slow or spotty connections, and if there are any problems with your javascript (like you accidentally relied on a very new feature that's not commonly supported in browsers, you didn't use a polyfill, and you only tested in one browser, and then a user visits with an incompatible browser), then things still mostly work.
If you make a site built using React, you should do server-side rendering so that the each page's HTML contains the initial render of the page. The easiest way to do this is to use Next.js or Gatsby. You make your pages out of normal React components. The gotcha is that your React components won't ever have their useEffect/componentDidMount callbacks or any of their event handlers fire for users who don't load the page javascript. As long as your React components put out useful HTML in their initial render, as is good practice anyway, you should be fine.
You can create much more interactive menus with just CSS these days. Had a dabble a while back on my ill fated blog, infiniterminals.com
Honestly I appreciate wanting to be no-js but such menus are a lot, lot less accessible than good quality Javascript menus.
I agree. One common JS library for example is called HoverIntent, and it's smart about not closing the menu just because you accidentally moved the mouse off of it for a tenth of a second. For people who have trouble controlling their mouse, this can make hover menus substantially easier to use.
I know a lot of people assume that JS == inaccessible, but that's not the case. Screen readers and similar tools do work with JS today.
I implemented a menu yesterday that has nice accessibility: https://gfycat.com/positiveseverehen. Not a single line of JavaScript.
Looks really nice, I'd love to see a demo somewhere.
(And it's not that I don't believe you, it's that it's unlikely to be possible in css to be truly accessible with regards to the accessibility features mentioned in my other post)
I'm currently making a docs website, I can give you a link to it when it's ready. (Should be soon, the main thing was the menu, the rest is just markdown pages.)
tbh the only thing I couldn't do with css only is keyboard trapping. When you're in that mobile version, you could tab out and reach the rest of the page. Haven't found a way to solve that yet. Most likely I'll just solve that with JavaScript and consider it acceptable.
Here is version 0.0000001: https://apostolique.github.io/GitHubActionsFun/.
Hopefully there aren't too many bugs.
Edit: rip some issues with the styles.fixed had badly configured purgecss.Feels quite smooth. I like it.
As a tip, it would be more screen reader-friendly If you used
<li>in there as well. Right now it'll be read as assorted links on a page, rather than a single list of navigation items.I'm seeing a lot of conflicting information about doing that. Apparently screen readers will say a lot of useless information when a nav contains a list of links. I'm basing my work on Tailwind UI which doesn't use that, you can see an example here: https://tailwindui.com/preview (check the code on the first one for example "Dark nav with white page header").
But I just tested in the Lynx browser and this is how it looks:
https://i.imgur.com/nFcBpNZ.png
https://i.imgur.com/aQo7Ak8.png
https://i.imgur.com/7k0wD0y.png
I'll try using a list.
(I think a documentation website should work well with Lynx.)
Screen readers can be configured to be more or less verbose. I'm not sure why Tailwinds opted not to use them here, but in my opinion it's best to give the client as much context as possible. They can decide what to do with it.
I've never used Lynx myself. I'd be curious to see how it handles newer layout tools like flexbox and grid.
How so? What is missing from a CSS based menu that JavaScript would solve? I can only really think of not supporting older browsers (if the CSS uses some fancy new features), but apart from that (from a accessibility perspective) I've a hard time coming up with something concrete.
@wes already gave an example; to add to it, there's a lot of other tricks high quality menu libraries will implement to detect "intent". For example, let's say you're over a menu that looks like this:
And you're over Top 1 so it looks like this:
You want to click "Leaf 2" but in doing so, you briefly hover over Top 2. It won't immediately register intent and will let you click Leaf 2 without updating the submenus.
Some of the C++ libraries even look at the direction your mouse is moving and its velocity.
Menus should also be accessible with focus-based keyboard navigation, which most CSS-only menus are not or cannot be.
DOM-wise, menus should have role and aria attributes to identify them and tell whether or not they're expanded and what they expand into. All of this is very well supported to give screen readers a good navigation experience.
The issue of immediately switching between menu items when hovering changed can be resolved with a simple
transition-delay. I typed up a brief sample:The keyboard navigation is much simpler to resolve if each menu item contains an anchor tag. That way navigation can be done with the tab key. As for the aria attributes they are supposed to be used for rich internet applications and besides if you use nav and menu I think defining the roles is superfluous (they are already defined for those elements I think, but not 100% sure).
I think CSS animations do help the issue, but aren't quite as good at determining intent as a Javascript solution would be.
This is definitely helpful too, but keep in mind that tabbing is only one method of navigation. Ideally you would cover all bases for accessibility.
For instance, sighted users who navigate via keyboard will require visual feedback to better understand menu context. Just seeing the link target doesn't provide enough information about site hierarchy, for example.
Screen readers can also navigate from other approaches than just tabbing, such as jumping to specific elements. While many screen reader users operate from sound alone, some also retain limited visibility and can also use that extra visual information from seeing menus open. I don't believe that is possible in your example above.
e: grammar
You are right, capturing the intent of the user based on dynamic behaviour would be infeasible with CSS. Using the delay trick gets you most of the benefits, but I sure you could make something even better using js. OTOH using the CSS approach would allow for progressive enhancement whereas using the js option wouldn't.
I'm going to see if using the
:focusselector could be used to enable the visual feedback on keyboard navigation :) fun challengeJust a quick follow up I managed to get the menu working with keyboard navigation (tabbing only no fancy arrow key nav, but still usable) by includin an anchor tag (which you'd probably have either way). Then complementing the hover selector with a
menuitem menu:focus-withinthat also sets themax-heightand you are all good. I believe this approach would also work with nested menus. If the:has()pseudoselector gets widespread adoption you could get even fancier.So in essence at this point in time, if you want a simple and accessible drop-down menu, there is no reason to reach for JS.
I think I inadvertently bash.org'd you into making your menu more accessible. :) I'm glad you found some nice solutions - sounds like a win/win for everyone involved!
http://www.bash.org/?152037
I've seen a lot of people use CSS menus (in the context of this article), which looked good to me, but I never tested them on mobile.
Yeah it was more of an experiment with what can be done with CSS alone, I feel it turned out reasonably.
I love the colors you selected. I think it’s a beautiful palette
Thanks, but its actually a Hugo theme that I tweaked the layout of. Hugo - Base16
If you're looking for a simple static website and have found somewhere to host it then Hugo is a wonderful tool, write your blog entries in markdown and regenerate the site, upload the public folder to you hosting provider and it's all done.
Here's a bone to chew on:
Do you really need dropdown menus?
They're supposed to be unobtrusive, save visual space, only show up when needed – but they're fuckin' uncomfortable to navigate. Mouse? Takes precision of movement, and is famously prone to slipping onto another item. Keyboard? I can't even navigate to yours with [Tab]-ing through the links.
In navigating the Web – and static blogs in particular – I find that most of the time, I'm passively filtering away irrelevant elements. That navigation bar at the top of the page (provided it stays there, and doesn't follow me around as I scroll), that fixed logo in the top-left corner that takes you to the home page, that subheader with tags and categories and what have you... As long as it isn't actively taking up my attention, I won't notice it. My assumption is: most people are the same, 'cause if I can filter out this kind of information (and I usually can't), others don't even know this may be an issue.
The front page of your blog loads in under 7 seconds on simulated slow 3G connection without cache. With most of the heavy stuff cached, it goes under 3 seconds. This is perfectly acceptable. Instead of listing all the kinds of deep division of content you have in your blog, you could simply link to both the "Categories" page and the "Tags" page, and let the user browse on their own.
Granted, it's a half-baked content strategy – it doesn't even take into consideration who your users are and what sort of content they expect from your blog – but it does give you some perspective on how the navigation could be done.
No. I am aware they are imperfect, it was more of a proof of concept.
A good portion of the loaded content is Google fonts which I'm keen to remove now after reading other posts on here recently.
The default template lists all the "Categories" and "Tags" at the bottom of the page.
Yeah, there's a lack of direction because I wasn't sure what direction it would take and wanted to not pigeon-hole myself into writing specific content.
Do you have any good examples of how a small personal blog should be structured? The taxonomy for posts, depth of content, etc.
Your best bet, should you still want to retain the fonts used (they are rather fitting), is self-hosting the fonts. Google allows this by default. If you want to download the fonts to host yourself, you can use this Web app.
That's well and good. I assumed that this is what you want your users to find first, given that you've chosen these items for the dropdown. If it were, your best bet would've been providing a clear headline link to those: this would've let users know immediately where to go and what to see.
Alas, I'm not too keen on thrawling the blogosphere.
The best advice I could give here, provided you want one, is to put forth what you want your visitors – both first-time and regular – to see first. If you use your own terms for much of the stuff, providing link to a dictionary would be meaningful. If you host a small, Twitter-ish list of short posts that don't jive well with your other content, giving the link to that separate Twitter-ish space would help expose it to those who may not see it otherwise.
Make it as easy to get to the good stuff as you can, without bending over backwards. The lower the overhead of maintaining that "LOOKIE HERE" area of the blog, the easier it will be to change later, and trust me: you do not want to make the process of changing stuff even remotely difficult. This is where procrastination, anxiety, and the eventual ruin of your blogging process comes from: the discomfort of moving things around.
I like the colours of your blog, is there only one blog post?
Alas yes, the idea was to document stuff for myself to look back at and rediscover how i did things if I ever needed to revisit them. Didn't really work, I just don't have the motivation to type lengthy pieces. I always hated English at school for all the writing and unnecessary (in my mind) embellishment. It's also the reason I don't post on here much, the longer responses that people give with well thought out answers can be intimidating at times.
Shameless plug of my personal blog which I just use a bash script and pandoc to convert markdown to html: https://crdpa.github.io
You will see the size of the problem after installing something like NoScript on Firefox. 90% of the websites are unusable with JavaScript turned off, even if it only have text and some images. I constantly have to enable domains so I just gave up and uninstalled the addon.
Not a lot to chew on here, but you gotta start somewhere.
You could, make a fashionable, modern-looking slide-out menu with only HTML4 elements and CSS2 selectors. All you need is a checkbox, a label attached to it, and some form of navigation that precedes the main content on the page.