|An accessible CSS content hiding method|
does HTML5 make a legitimate use case for it
I stumbled upon an interesting content hiding technique the other day while looking for the latest on image replacement.
Using CSS clip as an Accessible Method of Hiding Content [adaptivethemes.com]
I couldn't really figure out the importance of this method over another until I read (a few times!) the discussion behind this - a Drupal Core issue [drupal.org]
This brought me back here: accessibility and <h1> header images [webmasterworld.com] - which after reading confused me further until I realised that here at WebmasterWorld, the talk tends to center around using things for SEO, and mainly involves hidden H1's and header images/logos
IMO there is a difference in reasons for hiding content/images - and the Drupal discussions highlight what they are - thank you
I read that AT (Assisted Technology) users use the <Hx> tags to "tab" through documents so the ability to be able to put <hx> headings, above every section of content, form or image gallery is a good thing, a navigational aid if you like, even though they may not be necessary for visual users who can see a search form or random image block for what they are. Is that then the genuine legitimate reason for hiding headers whether for image replacement purposes or not.
I'm not thinking about just the header logo (which by the way I do try to put as an actual image not replaced and not as an H1 header either) I'm talking about section headings, - HTML5 <section>s must all have headings - they play an important role together in the hierarchy of the document or <article>, which in turn is no more than the navigation of it, whether by user or BOT
from the Adaptive Themes post:
|Its relatively easy to hide content in Drupal using CSS, however its a whole different ball game to hide content and keep it accessible to all site visitors. Disabled web users may be using a screen reader or other Assistive Technology. For Drupal 7 we wanted a way to hide content that worked in all browsers and avoided many of the issues associated with current techniques. |
my bold, and you could just substitute Drupal for whatever ;)
The beauty of the clip method would apparently be that all, or at least all tested, according to the above two links, AT's "read" content hidden by it
what is it?
clip: rect(1px 1px 1px 1px); /* IE6 & 7 */
clip: rect(1px, 1px, 1px, 1px);
(any px amount, except 0 (zero), will do - as long as all four values are the same.. [added to clarify] - 0px works but is not read by ALL of the technologies tested hence the recommendation to use a non-zero value)
Apparently Drupal 7 is to have headers for all sections (in line with HTML5 recommendations) and the ability for the end user of the CMS to hide them would be essential for theming I suppose, which is why it surfaced in Core.
I can also imagine that this "hiding headings" will take over from the opposite way to tackle the same issue, as far a CMS providers are concerned anyway, which is to use CSS to insert pseudo content for visual labels only, this would not only be harder to convey semantically I suppose, but also harder to implement programatically - and I'm not altogether sure the various media stylesheets are up to it anyway? besides if AT users are already familiar with "tabbing" through heading elements and all or most technologies appear to have implemented some way, shortcut, for their users to do this (Opera has it implemented too I think) doesn't that make it, heading replacement/hiding, a legitimate use case - should we be adding headings as a navigational aid whether we need them visually or not
Not really with regards to the first part, except to be wowed by the collective expertise in that thread and all of the techniques I had never thought of for hiding content and the implications for situations I don't think about much (RTL).
With regard to the second part, I've had a number of discussions here on headings where the SEO-oriented members tend to look at the issue from an SEO-centric point of view, rather than a document structure point of view. That said, I think the idea of having H2s all over the place is a... unfamiliar.
I know that Drupal 7 is considered, above all, a usability release and they've put in a lot of hours and a fair bit of money into exploring usability issues, having involved some top testing labs and quality usability and accessibility experts. It will be interesting to see some of the results of this.
I have always had an issue with hiding content ... not much room for discussion there ;)
However, I think this is the biggest issue
I read that as premised on the idea that, consistent with the intention behind html5 document structure and therefore proper evaluation of content, sections will have headings - but for those coders/content writers who can't be bothered evaluating their content and marking it up correctly there will be a facility for them to avoid the html5 intent ... and it's Ok because it's accessible.
|Apparently Drupal 7 is to have headers for all sections (in line with HTML5 recommendations) and the ability for the end user of the CMS to hide them would be essential for theming I suppose, which is why it surfaced in Core. |
To me that just means coders/content writers can slap an html5 happy face on their code without regard for the html5 intent. Sheesh, if <section>'s are supposed to have headers, then if a section of content doesn't need a header it isn't a <section>. So this seems to be actively setting in place a means to allow <section> to be mis-used. div-itis turned section-itis. Just longer to type. Oh yay.
It may be accessible, but that does not make it good code.
I'm also wondering about the tab order for AT, how many have already made adjustments for multiple h1's - and what happens to the tab order when expected h1's are hidden/not present, etc.
I think identifying that perspectives inform the discussions about hiding content is insightful. But then, I've always been surprised that even at WebmasterWorld accessibility isn't treated as an aspect of "Code, Content, and Presentation" for the purpose of grouping related forums.
based on the above, my question would be "whose usability?"
|I know that Drupal 7 is considered, above all, a usability release |
I find it interesting that much of the accessibility impetus in the linked discussion is to aid theme creators and not the end users.
Or, put another way, they are attempting to make up for theme designer accessibility ignorance/shortcomings from within the Drupal core.
I view their intent as laudable, the result not so much.
I'm not really sure how this will be implemented in Drupal (has anyone actually looked at how this is implemented?). As it is now, all block (I'm not sure in Drupal parlance what a "section" is, but I assume that blocks will become sections?) have titles, but designers often choose to have them not display. I was thinking that this meant that rather than the title not being there at all, as is currently the case, they would have hidden titles.
So for the visual reader who can see right away that this is the Navigation section, no title is shown, but for the screen reader, who may want named sections to be able to quickly navigate from one to the other, that information would still be available, just not visible.
>>attempting to make up for theme designer accessibility ignorance
Fair enough, but I think that systems like Wordpress and Drupal that are often implemented by people with little clue about web development at all. They can't make up for this with some universal rule, but they should do their best to provide the best possible defaults, faulty though these may be.
Granted, any defaults provided programatically are going to be limited and could have the consequence of making people believe that they don't need to do anything themselves. But a truly competent theme designer will be able to override the defaults and provide a design and interface that makes more sense within the context of their site.
So I don't see it as a binary choice between doing it half-ass and doing it right, but a ternary choice between doing it right, doing it as well as possible with universal programmatic defaults and not doing it at all.
But I say that without having looked at how it's implemented and whether it is actually better than not doing it at all.
|(I'm not sure in Drupal parlance what a "section" is, but I assume that blocks will become sections?) have titles, but designers often choose to have them not display. |
I've looked at it, which is why it caught my eye, @ergo you are right, "block" would be the parlance for sections, but in my minds eye, although it took me a long time to get used to their "Drupal speak" it's about the closest thing to sections in non-designer speak, perhaps why it is so difficult to see? (for some of us!)
|they are attempting to make up for theme designer accessibility ignorance/shortcomings from within the Drupal core. |
with that I'm strongly tempted to disagree, this to me is a core issue that has cropped up and has been fixed because of the attention to accessibility rather than SEO or design..
The more I think about it the more I can see that while yes with both WP & Drupal the end user may well "expect" thing to just hide things themselves at the click of a checkbox the bit behind can be as simple as
display:none or it is better thought out perhaps?
with Drupal6 you can either hide your titles or change them to suit, the power behind the "hiding" is as important for SEO as it for navigation/access - at least I think so
@ ergophobe - I wonder if this is just a sneak preview of "section of content"/"HTML5 <section> element" confusion we will "enjoy" in the future.
I appreciate users of AT will still have access to the headers, but it remains that if the "sections" are html <section> elements then they need headers, so it is mis-using the element to have headers that do not display. Of course it is different if the sections are actually you "blocks" of content rather than html <sections> elements.
I don't agree with your conclusion - but I do agree your point is valid. And you gave me my new word for the day ;)
|So I don't see it as a binary choice between doing it half-ass and doing it right, but a ternary choice |
Using clip as a means to hide content rather than display to avoid the user agent rendering issues only works if clip doesn't create a whole set of new issues. I looked at clip for a visual design outcome a few years ago, but implementation was so poor it wasn't usable. Based on the articles, testing doesn't seem that robust, including not yet testing all AT's. Seems to me this clip can't be touted as an accessibility-driven accessible solution until testing shows it is accessible, and doesn't create other problems.
|this to me is a core issue that has cropped up and has been fixed because of the attention to accessibility rather than SEO or design.. |
Me too. Although I wish they weren't frequently constructed as being in opposition, and given priority in that order. But I do think the argument that this is a way of making up for ignorance/knowledge shortcomings has merit - and add on laziness, and the "it doesn't affect me personally, so I won't bother" brigade as well.
|the power behind the "hiding" is as important for SEO as it for navigation/access - at least I think so |
But clip is cool, I had so much a fun when trialling it. I've never liked display:none because of the reflow issues, so clip would be an improvement - if robust testing shows it doesn't create other issues.
The real issue for me, is that the most logical property really is visibility. I had wondered if the html5 draft would revise hidden so an empty element took up no space in the layout, or extend collapse to all elements. It hasn't, which seems a missed opportunity.
>>my new word for the day
Heh heh... geek speak - [en.wikipedia.org...]
I don't know as I've ever seen it in a non-programming discussion.
As to the rest... I'll have to just concede that until I have time to really look into what's actually going on. You certainly have a strong point when you say that when a spec calls for a heading, it's fair to assume that the spec writers didn't imagine people would interpret that to mean an invisible heading.
|Seems to me this clip can't be touted as an accessibility-driven accessible solution until testing shows it is accessible, and doesn't create other problems. |
I hope I've worked out that sentence OK, and haven't picked it up wrongly - all I can say is fair enough, I don't think anyone is actually touting it? just thought it was interesting given it does actually pass more "real world" tests than a theoretical test ;) Yes it's more accessible than display, visibilty and text-indent..(seen some those tricks before haven't we?) - but have you seen a better one yet or a real life case which suits everyone? - I know you are anti hidden, so am I really - but working with the CMS's and letting them evolve is very illuminating - the what should be be done (boring "spec" wise) as opposed to the what is actually being used are different things.
I'm not sure that I actually mind which method is the best for both design or the accessible AT world - it just seems clear that this is one area that's very much evolving by itself, and the similarity between user behaviour and "rules" are interesting
I don't see this as an abuse of headers but a very important use of them - I don't for one minute think this is why HTML5 have their "sections" or why Drupal has its "blocks" - it's more a convergence of something that would have happened anyway because it's natural perhaps?.. I like the idea of tabbing - not tab index which should never change but tabbing between headers (headlines) or section(division) headings..