Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Another way is to use the checkbox-and-CSS trick. You add a hidden checkbox next to the element you want to hide, add a label to trigger the checkbox, and then use a + selector to toggle the visibility based on the state of the checkbox. Like this:

    <label for="spoiler">Toggle spoiler</label>
    <input type="checkbox" id="spoiler"/>
    <div id="spoilerContent">Spoilery stuff goes here</div>
    <style>
    #spoiler, #spoilerContent{display: none;}
    #spoiler:checked+#spoilerContent{display: block;}
    </style>
You can also use a variation of this for tabs - just use radio buttons instead - and accordions.


IIRC that will mess up screenreaders though. The detail tag is specifically made for this sort of thing and is therefore almost certainly more accessible.


And accessibility trolls are hot right now.


I hope my fellow HN readers never need an accessibility troll to advocate on their behalf.


Yes. But I believe details / summary is considered more accessible. Since its in the spec it's something AT has or is working towards.


It be more correct to say what grishka said above: "that will mess up screenreaders though"

But if it's more accessible depends on the target user. If you're target are IE users or users with very old browser versions, for one reason or another, more accessible would be to use the CSS toggle trick. But if indeed your target user are users using screenreaders and using recent browsers, then details and summary elements would be more accessible.

A bit anal, but important to consider when talking about accessibility, it's very context sensitive.


Accessibility is specifically about making things accessible to those with disabilities. Unless you are making a joke about the intelligence IE users or those using old browsers, accessibility isn't about maximizing potential reach.


Accessibility is often thought of as just making things accessible to people with disabilities, but it's not just that. Accessibility is mainly about maximizing the reach, not just for people with disabilities but people in any situation.

For example, people who live in South America usually have a lot worse internet connection, and more likely to be on mobile networks, than people in the west. If you're audience is mainly in South America, working on making your application accessible, means making sure your application has low bandwidth usage, can deal with high latency and jitter, and works well for phones.

One only has to look at the definition of the word "Accessibility" to see why you're wrong: "accessibility - the quality of being able to be reached or entered - the quality of being easy to obtain or use - the quality of being easily understood or appreciated".

Not sure where the focus on people with disabilities came from, it's important, but accessibility is much bigger than just that.


> Not sure where the focus on people with disabilities came from

You are right, accessibility _can_ take into account degraded environments, but if you don't know why disabilities are focused on, that suggests to me you are philosophizing on the word, and not addressing actual technical standards that have been put in place. Just google it


"Just Google it" doesn't scream curious conversation exactly.

Your argument was "Accessibility is specifically about making things accessible to those with disabilities" which by no definition of the word, is true. Look it up.

Not sure why I'd have to read the various specifications again when I've already done that. I'm still of the same impression (like most others) that accessibility is much bigger than just making things work for those with disabilities.


What's IE? ;)


Thanks!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: