Hi all
Today I got a review of Vector's accessibility from an employee of the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This is by no means a full evaluation, just the result of having a casual look. I visited them with Till and Maria of Wikimedia Germany a week ago, and Sebastian Brückner kindly agreed to take a peek.
At the bottom is the full mail in German, but I'll try to give a quick summary of the main points in English here:
1) CSS uses a:hover but is missing a:focus; Thus, there's no highlighting when navigating links with the keyboard. This should be trivial to fix - or are there any problems with this?
2) The tab order is inconvenient. IE8 und FF3.6 show first the search box, then the show/hide toggles from the sidebar, then content, then the top bar, and only then the actual navigation items from the sidebar. This is probably because the toggles get inserted by JS, i guess. Opera 10 goes to searchm then the toggles, then back to search. That's bad.
3) hidden (collapsed) menus use display:none. This makes them inaccessible to screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
4) Tables are used for layout a lot. This is mostly true for content, especially for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's going to be very hard though to get wiki editors to use proper css based code for table layouts.
Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff() looks fairly sane, so perhaps it could be done.
5) In image thumbnail boxes, the "zoom" link is before the caption, so people have to skip over it every time. Perhaps it could be moved after the caption.
6) Image thumbnails have an empty alt attribute. This seems like a bug to me - was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?
While there are some tricky issues (like the tables), most of the above should be fairly easy to fix. And would improve the experience for people with bad vision quite a lot. I'd volunteer to implement at least the easy changes, but it would be good to have some feedback first. So, what do you think?
-- daniel
-------- Original-Nachricht -------- Betreff: Usability von Wikipedia Datum: Fri, 18 Jun 2010 13:16:49 +0200 Von: Brückner, Sebastian Sebastian.Brueckner@dzb.de An: daniel.kinzler@wikimedia.de
Hallo Herr Kinzler,
wie im Gespräch am 11.06.2010 besprochen, habe ich einen Blick auf den neuen Wikipedia-Skin geworfen.
Dabei sind mir einige verbesserungswürdige Punkte aufgefallen, teilweise sind (vermutlich) auch nicht viel Handgriffe zu tun.
Positiv hervorzuheben ist der hohe Kontrast der Überschriften, Links und Texte sowie die Skalierbarkeit der Seite, ohne das Überlappungen oder Abschneidungen auftreten.
Ein schnell zu erledigender Punkt wäre die Ergänzung von a:focus zu a:hover im CSS, da bei Tastaturbedienung keinerlei Fokushervorhebung auftrat. Bei Mausbedienung wird hingegen eine Unterstreichung bei den Links hinzugefügt. Hinderlich oder irritierend könnte die "ungewöhnliche" Tab-Reihenfolge sein. Im IE8 und FF3.6 werden zuerst das Suchfeld, dann die 3-4 Aufklapplinks der Navigation, der Inhaltsbereich, der Header und anschließend erst die restlichen Navigationlinks und der Footer angesprungen. Im Opera 10 konnte ich hingegen nur die Suche und die Aufklapplinks antabben.
Auf der Startseite fiel mir auf, dass die unaufgeklappten Links mit display:none; versteckt werden, damit sind sie allerdings auch für Screenreadernutzer nicht auffindbar. Lösungsmöglichkeit wären z.B. die Positionierung außerhalb des sichtbaren Bereichs oder die Höhe auf 0 setzen. Zudem wurden Layouttabellen verwenden, es sind nur vier Zellen, was keine große Barriere darstellt, allerdings wäre auch diese mit wenig CSS vermeidbar. Ebenso ließen sich die doppelten Links vermeiden, die durch die getrennte Verlinkung von Icons und Texten auftritt. En masse tritt dies bei den Portallinks und Schwesterprojekten der Startseite auf.
Auf einer Inhaltsseite (die von Leipzig) fielen mir ebenfalls Layouttabellen auf, hier aber nur ein- oder zweizellig, aber grad deswegen eigentlich gut ersetzbar. Sämtliche Thumbnails an der rechten Seite des Inhaltsbereichs enthielten leere alt-Attribute. Das ist schon mal besser als gar keine, allerdings übergehen manche Screenreader solche Grafiken dann. Da nach der Grafik auch erst der vergrößern-Link folgt, ist der "Weg" zur Bildunterschrift doch länger als nötig. Vllt. könnte man hier die Reihenfolge optimieren oder die Bildunterschrift als Alternativtext vergeben, was aber natürlich zu ebenso unschönen Dopplungen führen kann.
Ich hoffe dass es sich nicht allzu schlecht anhört, denke aber das einige Punkte schnell behoben werden können. Eine Begutachtung der Bearbeiten-Seite war mir aus Zeitgründen noch nicht möglich, dass würde ich Anfang/Mitte nächster Woche nachholen. Dann auch gern mit einem blinden Kollegen aus unserem Haus.
Für Rückfragen und Anmerkungen stehe ich natürlich gern zur Verfügung.
Mit wochenendlichen Grüßen Sebastian Brückner
--- Sebastian Brückner Deutsche Zentralbücherei für Blinde zu Leipzig Informatik Telefon: (03 41) 71 13-180 Fax: (03 41) 71 13-125 E-Mail: sebastian.brueckner@dzb.de
Hi all,
Many thanks to Sebastian from the DZB for his quick accessibility inspection.
I wanted to comment on two things.
- hidden (collapsed) menus use display:none. This makes them inaccessible to screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
I doubt this will be a reasonable solution. It is correct that hidden menus are display:none. The menu can be expanded, but this is not clear to the screen reader user as he wouldn’t suspect he can activate a heading. (If the heading would have an onclick event this would be indicated by the screen reader.) This problem can only be solved satisfactorily by using WAI-ARIA.
Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
There is no such thing a a screen reader plugin, so you can’t detect them easily or reliable. They inject filters into browsers (BHO for IE) or make use of known accessibility interfaces.
I thank everybody who is moving forward accessibility for Wikimedia projects. It is important to millions of users with disabilities worldwide.
Cheers, Maria
Daniel Kinzler wrote:
Hi all
Today I got a review of Vector's accessibility from an employee of the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB). This is by no means a full evaluation, just the result of having a casual look. I visited them with Till and Maria of Wikimedia Germany a week ago, and Sebastian Brückner kindly agreed to take a peek.
Thanks to all.
- hidden (collapsed) menus use display:none. This makes them inaccessible to
screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
Maria added:
It is correct that hidden menus are display:none. The menu can be expanded, but this is not clear to the screen reader user as he wouldn’t suspect
he can
activate a heading. (If the heading would have an onclick event this would be indicated by the screen reader.) This problem can only be solved satisfactorily by using WAI-ARIA.
That looks like a bug. CollapsibleNav is using mousedown and keypress events instead of onclick.
- Tables are used for layout a lot. This is mostly true for content, especially
for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's going to be very hard though to get wiki editors to use proper css based code for table layouts.
Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff() looks fairly sane, so perhaps it could be done.
We also have real tables use cases, but it may be worth to try something like this.
- Image thumbnails have an empty alt attribute. This seems like a bug to me -
was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?
Those should have a title attribute. We used to have alt attribute equal to the title, but that was removed for duplicating it and being in fact ignored. Is some screen reader preferring alt over title? See r41837.
2010/6/18 Platonides Platonides@gmail.com:
That looks like a bug. CollapsibleNav is using mousedown and keypress events instead of onclick.
We have been using mousedown instead of onclick to improve perceived performance, IIRC. Replacing mousedown with onclick would eliminate the need for hooking keypress AFAIK and make screen readers happy.
Roan Kattouw (Catrope)
Hello Platonides,
Those should have a title attribute.
On German Wikipedia I see no titleattribute if I specify a caption for an image.
We used to have alt attribute equal to the title, but that was removed for duplicating it and being in fact ignored. Is some screen reader preferring alt over title?
The most often used screen reader JAWS behaves like this: By default it uses the alt tag. The user can change this by altering the setting to “use title” or “use longest” and some other fancy stuff. But this is a global setting, so you don’t really want to force the users to change their setting.
If no alt attribute is set, JAWS could disregard the image. In our case images are always surrounded by links. Having no alt attribute JAWS uses an annoying fall back solution: it speaks the image file name.
We discussed this some weeks ago in the German Wikipedia. The preferred solution would be:
1. If [[File:...|alt=...|...]] is given, use this text for the alt attribute. 2. If no alt text is given, use the text given as the thumb caption. 3. If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
I hope that clarified the problem.
Kind regards, Maria
Hello all,
I have a second suggestion for the alt problem that will require the use of WAI-ARIA, namely aria-describedby. Drawback: That is currently only valid in HTML 5. But it would be the better solution since alternative text and caption text are two different things (see also http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images).
Using WAI-ARIA the solution would be:
1. If [[File:...|alt=...|...]] is given, use this text for the alt attribute. 2. If no alt text exists, use the “simplified” file name. 3. Add aria-describedby="ImageCaption" to the img tag. (With ImageCaption being the id of the caption.)
The screen reader then can associate the caption with the image.
Cheers, Maria
P.S. Please not that the handling of alt text currently differs depending on whether you use thumb, frameless or pixel (see http://de.wikipedia.org/wiki/Benutzer:Raymond/alt). It must be consistent.
2010/6/18 Daniel Kinzler daniel@brightbyte.de:
- hidden (collapsed) menus use display:none. This makes them inaccessible to
screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
display: none seems completely appropriate here. The screen readers should allow the user to expand the menus just like sighted users can -- if that can't be done, that's what should be fixed.
Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
That sounds unreliable . . . you probably can't detect this reliably, and if you could, the other mode probably wouldn't be maintained as well as the primary one. Is this necessary?
Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff() looks fairly sane, so perhaps it could be done.
This sounds like it's very impractical just on an HTML level. You'd have to duplicate the display exactly, and table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all. Also, I'm not sure what the actual benefit would be -- do screen readers treat div soup better than presentational tables?
- Image thumbnails have an empty alt attribute. This seems like a bug to me -
was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?
I've never been clear on what's the best thing to do here. Don't add alt at all (so screen readers can fall back intelligently)? Use the filename? I'd think it would be best to not add alt at all, if we think the image isn't presentational, so user agents can handle it intelligently. This is what HTML5 currently recommends:
"As a last resort, implementors should either set the alt attribute to the empty string, under the assumption that the image is a purely decorative image that doesn't add any information but is still specific to the surrounding content, or omit the alt attribute altogether, under the assumption that the image is a key part of the content." http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-markup-generators
On Fri, Jun 18, 2010 at 10:57 AM, Maria Schiewe maria.schiewe@wikimedia.de wrote:
We discussed this some weeks ago in the German Wikipedia. The preferred solution would be:
- If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
- If no alt text is given, use the text given as the thumb caption.
- If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
For (2), wouldn't that result in the screen reader reading the text twice? Some captions can be pretty long. We used to do this, but eventually changed it, IIRC in response to complaints.
Also, why is (3) preferred to just not providing an alt attribute (other than standards conformance)? HTML5 currently recommends against this explicitly:
"Markup generators should generally avoid using the image's own file name as the alternative text. Similarly, markup generators should avoid generating alternative text from any content that will be equally available to presentation user agents (e.g. Web browsers)." http://www.whatwg.org/specs/web-apps/current-work/multipage/embedded-content-1.html#guidance-for-markup-generators
If this is wrong, then maybe that text in HTML5 should be changed.
On Fri, Jun 18, 2010 at 11:41 AM, Maria Schiewe maria.schiewe@wikimedia.de wrote:
I have a second suggestion for the alt problem that will require the use of WAI-ARIA, namely aria-describedby. Drawback: That is currently only valid in HTML 5. But it would be the better solution since alternative text and caption text are two different things (see also http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images).
Using WAI-ARIA the solution would be:
- If [[File:...|alt=...|...]] is given, use this text for the alt attribute.
- If no alt text exists, use the “simplified” file name.
- Add aria-describedby="ImageCaption" to the img tag. (With ImageCaption being the id of the caption.)
The screen reader then can associate the caption with the image.
What would the practical effect of aria-describedby be in a typical screen reader, compared to the status quo?
P.S. Please not that the handling of alt text currently differs depending on whether you use thumb, frameless or pixel (see http://de.wikipedia.org/wiki/Benutzer:Raymond/alt). It must be consistent.
This is for historical reasons. The unnamed parameter is used for a caption if there's a caption, and used for alt text if there's not. I wanted to change this when adding the alt= parameter, so that it would be consistent, but Brion thought it was best to remain compatible with existing content that used the unnamed parameter as alt text.
Hello Aryeh,
Thank you for your answers and questions.
The screen readers should allow the user to expand the menus just like sighted users can -- if that can't be done, that's what should be fixed.
It’s not about the screen reader preventing the interaction. The interaction will be the same as for keyboard-only users. The problem is that there is no indication that the element can be interacted with. It is a heading level 5. How can you know, it does something? The small arrow is not visible to blind people.
What can we do? If you use onclick="" JAWS, for example, will indicate that the element is clickable, so the user will either use the space or enter bar or the routing keys of the Braille display to interact with the heading. (Note: The element does not necessarily have the focus but rather a virtual focus within the screen reader’s view of the website. The screen reader then handles the clicking or focussing, so we must somehow tell it that there is interaction possible.) If you have one of the new screen readers supporting WAI-ARIA, you could build a semantically understandable menu (see http://www.w3.org/TR/wai-aria-practices/#menu).
Also, I'm not sure what the actual benefit would be -- do screen readers treat div soup better than presentational tables?
Divs are not spoken, but sometimes indicated by a blank line. Whenever you read from one cell to another, you usually get information about your position within the table, the reference to the header etc. If you have boxes really displaying data in a tabular way, that’s fine. But it’s not fine to have tables merely for the sake of layout. (That’s one core thing repeated by accessibility experts again and again.) You will get all this positional information which wouldn’t make any sense and slow down your reading. So, yes: div soup is better than table soup. (Screen reader do have some heuristics to detect layout tables and treat them differently, but the results are varying.)
I've never been clear on what's the best thing to do here. […] This is what HTML5 currently recommends […] “or omit the alt attribute altogether, under the assumption that the image is a key part of the content.” […]
Ah, shame on me. I totally forgot about the recommendation. This is useful and we should follow it.
Kind regards, Maria
On Fri, Jun 18, 2010 at 2:27 PM, Maria Schiewe maria.schiewe@wikimedia.de wrote:
It’s not about the screen reader preventing the interaction. The interaction will be the same as for keyboard-only users. The problem is that there is no indication that the element can be interacted with. It is a heading level 5. How can you know, it does something? The small arrow is not visible to blind people.
What can we do? If you use onclick="" JAWS, for example, will indicate that the element is clickable, so the user will either use the space or enter bar or the routing keys of the Braille display to interact with the heading. (Note: The element does not necessarily have the focus but rather a virtual focus within the screen reader’s view of the website. The screen reader then handles the clicking or focussing, so we must somehow tell it that there is interaction possible.) If you have one of the new screen readers supporting WAI-ARIA, you could build a semantically understandable menu (see http://www.w3.org/TR/wai-aria-practices/#menu).
I don't know what we can do, since I'm not familiar with how AT works. However, I'm pretty sure that making it height: 0 instead of display: none is not a good solution. If it actually works at all to hide stuff from AT, it's only because the AT is buggy, and we shouldn't rely on that. Kind of like setting "position: absolute; left: -1000000px". Giving it an onclick handler sounds like a much better idea, if that will work. (We can keep the existing onmousedown handler too, so sighted users' experience doesn't suffer.)
I don't know why JAWS treats onclick differently from onmousedown here, though.
Divs are not spoken, but sometimes indicated by a blank line. Whenever you read from one cell to another, you usually get information about your position within the table, the reference to the header etc. If you have boxes really displaying data in a tabular way, that’s fine. But it’s not fine to have tables merely for the sake of layout. (That’s one core thing repeated by accessibility experts again and again.) You will get all this positional information which wouldn’t make any sense and slow down your reading. So, yes: div soup is better than table soup. (Screen reader do have some heuristics to detect layout tables and treat them differently, but the results are varying.)
Oh, I see. That's really terrible, then, and we should avoid presentational tables if at all possible. I think this really has to be done on the content side, though, not on the software side -- auto-translating tables to divs sounds like a bad idea.
Maybe we could remove attributes like cellpadding, cellspacing, align, etc. from the attribute whitelist. That would make it much harder to use presentational tables, wouldn't hurt non-presentational table use much, and would also improve our standards conformance (HTML5 bans them). We'd have to announce this way in advance and give people tools to adapt content before we break everything, but it'd be doable if we really wanted.
Ah, shame on me. I totally forgot about the recommendation. This is useful and we should follow it.
I'm fine with that. However, I'm not sure if we should assume that images are probably presentational, or that they're probably meaningful. A lot of images on Wikipedia are decorative, but a lot aren't. If we omitted the alt attribute entirely, it would help to alert people by triggering validation errors, so maybe that's the best approach. It would help if we gave people tools to spot bad alt text -- like have a preference that displays alt text in small print under the image, with a clear warning if there's no alt text specified.
* Aryeh Gregor Simetrical+wikilist@gmail.com [Fri, 18 Jun 2010 15:40:54 -0400]: ....
Oh, I see. That's really terrible, then, and we should avoid presentational tables if at all possible. I think this really has to be done on the content side, though, not on the software side -- auto-translating tables to divs sounds like a bad idea.
Maybe we could remove attributes like cellpadding, cellspacing, align, etc. from the attribute whitelist. That would make it much harder to use presentational tables, wouldn't hurt non-presentational table use much, and would also improve our standards conformance (HTML5 bans them). We'd have to announce this way in advance and give people tools to adapt content before we break everything, but it'd be doable if we really wanted.
Maybe it would be better to introduce non-standard (user-defined) attribute of element (tag), to indicate the type of table ("real table" or "layout table"), instead of breaking existing code? Then, screen readers could easily pick the value of table element attribute to guess whether column number and / or column header should be repeated or not. I haven't looked what HTML5 specification says about validation of user-defined attributes, though. Dmitriy
On Sat, Jun 19, 2010 at 9:59 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
Maybe it would be better to introduce non-standard (user-defined) attribute of element (tag), to indicate the type of table ("real table" or "layout table"), instead of breaking existing code? Then, screen readers could easily pick the value of table element attribute to guess whether column number and / or column header should be repeated or not. I haven't looked what HTML5 specification says about validation of user-defined attributes, though.
I think you could do something like <table role="presentation"> in HTML5. That would be invalid, since <table> must only be used for tabular data, but it's invalid already (just not automatically detectable). In theory, we should be able to mark it up so that at least ARIA-supporting UAs treat it reasonably.
It would be better to just use non-table markup, though.
On Sun, Jun 20, 2010 at 5:33 AM, Tisza Gergo gtisza@gmail.com wrote:
IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare. Tables have an intelligent width computation algorithm (which might not be consistent between browsers, but still works pretty well in practice), AFAIK you cannot do anything even remotely similar with divs and display: block. And there are a lot of complicated use cases for navboxes - stacking them inside each other, making them collapsible etc. (There are easier targets such as {{ambox}} which doesn't really take advantage of having a table-based layout.)
I'm pretty sure that infoboxes can be done just fine with divs. Not exactly as they are now, but well enough. You can't get the exact auto-width algorithm for the cells, but in typical infoboxes it will be fine if you just set it to 50% or something. And even if that's not perfect, we could use display: table for everything but IE6/7, so only they get the slightly bad widths.
Those all have CSS equivalents, so all it would achieve is to make presentational tables look uglier in older browsers where the CSS versions of those attributes are sometimes buggy.
They don't have CSS equivalents that are realistically usable inline. For instance, to simulate the padding attribute, you'd have to add padding to each cell's inline style, as far as I know.
Presentational images do (or should) set the click attribute most of the time; that might be a useful heuristic to set alt="".
There is no attribute in HTML named "click", and I don't see any documentation for a wikitext image parameter by that name either.
Aryeh Gregor <Simetrical+wikilist <at> gmail.com> writes:
I'm pretty sure that infoboxes can be done just fine with divs. Not exactly as they are now, but well enough. You can't get the exact auto-width algorithm for the cells, but in typical infoboxes it will be fine if you just set it to 50% or something. And even if that's not perfect, we could use display: table for everything but IE6/7, so only they get the slightly bad widths.
Infoboxes would do fine, navboxes not so much. Consider something like [1], how would that work with fixed widths?
If I remember correctly, there was an effort a while ago to make navbox markup less ugly (make it use a single table at least, instead of one table stacked into another), and even that didn't work in more comlicated cases like navbox subgroups.
Also, you can use visibility: collapse with collapsible tables, which looks much nicer in certain cases (when the table cannot be set to fixed width for some reason).
They don't have CSS equivalents that are realistically usable inline. For instance, to simulate the padding attribute, you'd have to add padding to each cell's inline style, as far as I know.
You could set it to inherit for td/tr in the sitewide css, and then set a single value inline on the table. Anyway, only modern browsers can handle CSS table layout properties, and those browsers don't need presentational tables in the first place. So the question is, do we really want to wreck a number of templates (or at least make them uglier) for the ~50% readers who use IE6/7, because of the tiny fraction who use screen readers? (Or because of standards purity, if role="presentation" works well with screen readers.)
There is no attribute in HTML named "click", and I don't see any documentation for a wikitext image parameter by that name either.
Sorry; I meant the "link" wikitext parameter but remembered the name wrong. The point is, when you use images as icons or similar eye candy, and the pointer changes to link style over it, the reader will expect something more relevant than an image description page, so link= should be used. Conversely, when it is used, it is a good guess that the image is purely presentational.
[1] http://en.wikipedia.org/wiki/Template:Protected_Areas_of_Colorado
On 6/21/10 2:57 AM, Tisza Gergo wrote:
Aryeh Gregor<Simetrical+wikilist<at> gmail.com> writes:
You can't get the exact auto-width algorithm for the cells, but in typical infoboxes it will be fine if you just set it to 50% or something.
As I mentioned in another post, this is probably a case where you actually do want a <table> tag.
Side note: it's rarely worth considering the table-* CSS attributes.
1) They aren't supported by all the browsers we care about.
2) If you're tempted to use them, it usually is a sign that you should try something else. In my opinion, they are only useful if:
- Your data really isn't tabular, AND
- Your data can't be divided up in a different way without sacrificing semantic understanding, AND
- The contents of a certain element are very unpredictable in a way that leads to unpredictability of height or width in your chosen layout; AND
- overflow or scrolling the elements is not an option; AND
- you need the width or height of other adjacent elements to match exactly (for example, the blocks are tinted in some contrasting color compared to the background; OR there are vertical rules separating elements; OR element content is supposed to be vertically centered).
There are situations that do meet all the above constraints, but they're relatively rare, and are usually aesthetic choices rather than hard requirements. Amendments to the above rules are welcome, I'm just trying to start a discussion.
On Mon, Jun 21, 2010 at 5:57 AM, Tisza Gergo gtisza@gmail.com wrote:
Infoboxes would do fine, navboxes not so much. Consider something like [1], how would that work with fixed widths?
If I remember correctly, there was an effort a while ago to make navbox markup less ugly (make it use a single table at least, instead of one table stacked into another), and even that didn't work in more comlicated cases like navbox subgroups.
Also, you can use visibility: collapse with collapsible tables, which looks much nicer in certain cases (when the table cannot be set to fixed width for some reason).
You might not be able to get the exact same appearance, but I'm very sure you can get something that looks just as good without using tables non-semantically. I don't have the time to actually try, though, particularly not when I doubt anyone will bother changing it. I asked someone I know who's more expert in CSS (an editor of some CSS specs, in fact), and he said it would only be a few minutes to change that template to be (in his words) "non-disgusting". Of course, that would mean no longer using {{navbox}}.
Sorry; I meant the "link" wikitext parameter but remembered the name wrong. The point is, when you use images as icons or similar eye candy, and the pointer changes to link style over it, the reader will expect something more relevant than an image description page, so link= should be used. Conversely, when it is used, it is a good guess that the image is purely presentational.
I'm not clear what you're saying. Images that are actually being used as links are the last thing you want to give empty alt text -- that would (as far as I understand) make it hard or impossible to click the link using a screen reader.
On 6/20/10 10:42 AM, Aryeh Gregor wrote:
I'm pretty sure that infoboxes can be done just fine with divs.
But wait -- an infobox is not a presentational table. Insofar as it presents a key-value structure, it's also semantically a table. So in this context, <table> tags are just fine, and it's up to screen readers to figure out a good way to present them. If we can provide hints through WAI-ARIA or other standards, great.
Maybe I'm not following this discussion 100% but we seem to be drifting from 'non-presentational <table>s are bad' to '<table>s are bad'.
-- Neil Kandalgaonkar |) neilk@wikimedia.org
Neil Kandalgaonkar schrieb:
On 6/20/10 10:42 AM, Aryeh Gregor wrote:
I'm pretty sure that infoboxes can be done just fine with divs.
But wait -- an infobox is not a presentational table. Insofar as it presents a key-value structure, it's also semantically a table. So in this context, <table> tags are just fine, and it's up to screen readers to figure out a good way to present them. If we can provide hints through WAI-ARIA or other standards, great.
The original comment was actually about the box structure on the main page. Which is a presentational table. Infoboxes are, arguabley, "real" tables. Though often it's a real table wrapped in a presentational table, wich is pretty bad.
-- daniel
On 06/21/2010 08:34 AM, Daniel Kinzler wrote:
The original comment was actually about the box structure on the main page. Which is a presentational table. Infoboxes are, arguabley, "real" tables. Though often it's a real table wrapped in a presentational table, wich is pretty bad.
Agreed. There's a lot of tag soup in Wiki* markup, so my comments aren't necessarily about any current use of <table>. I made a cursory glance at Infobox before I posted, but not a deep analysis.
Also, when I say "we", I mean, "someone else". ;) Sorry, I'm being bold elsewhere.
Aryeh Gregor <Simetrical+wikilist <at> gmail.com> writes:
Oh, I see. That's really terrible, then, and we should avoid presentational tables if at all possible. I think this really has to be done on the content side, though, not on the software side -- auto-translating tables to divs sounds like a bad idea.
IE doesn't recognize display: table-*, and without that simulating presentational tables is a nightmare. Tables have an intelligent width computation algorithm (which might not be consistent between browsers, but still works pretty well in practice), AFAIK you cannot do anything even remotely similar with divs and display: block. And there are a lot of complicated use cases for navboxes - stacking them inside each other, making them collapsible etc. (There are easier targets such as {{ambox}} which doesn't really take advantage of having a table-based layout.)
Given the prevalence of table-based layouts and the inadeqacy of CSS (as understood by some older but widely used browsers) to replace them, screen readers should be able to deal with them, or at least accept some sort of hint. WAI-ARIA does provide such a hint, the presentation role ( http://www.w3.org/TR/wai-aria/roles#presentation ); I don't know how widely it is understood by readers.
Maybe we could remove attributes like cellpadding, cellspacing, align, etc. from the attribute whitelist. That would make it much harder to use presentational tables, wouldn't hurt non-presentational table use much, and would also improve our standards conformance (HTML5 bans them). We'd have to announce this way in advance and give people tools to adapt content before we break everything, but it'd be doable if we really wanted.
Those all have CSS equivalents, so all it would achieve is to make presentational tables look uglier in older browsers where the CSS versions of those attributes are sometimes buggy.
I'm fine with that. However, I'm not sure if we should assume that images are probably presentational, or that they're probably meaningful. A lot of images on Wikipedia are decorative, but a lot aren't. If we omitted the alt attribute entirely, it would help to alert people by triggering validation errors, so maybe that's the best approach. It would help if we gave people tools to spot bad alt text
Presentational images do (or should) set the click attribute most of the time; that might be a useful heuristic to set alt="".
On Sun, Jun 20, 2010 at 11:33 AM, Tisza Gergo gtisza@gmail.com wrote:
Those all have CSS equivalents, so all it would achieve is to make presentational tables look uglier in older browsers where the CSS versions of those attributes are sometimes buggy.
How big is the market share of such buggy browsers (and what are they)? I'd prefer progress and nice, clean code over having to keep old cruft just because some people still use middle-age browsers.
Marco
Marco Schuster <marco <at> harddisk.is-a-geek.org> writes:
How big is the market share of such buggy browsers (and what are they)? I'd prefer progress and nice, clean code over having to keep old cruft just because some people still use middle-age browsers.
Amongst other things, IE6 and 7 do not understand the CSS property "border-spacing", which would be the easy way to replace cellspacing. Considering that IE8 reverts to compatibility mode on Wikimedia sites, that's a market share of 50% or so :/
Anyway, removing table-related attributes doesn't offer much advantage in itself. There will be a few validator warnings about it, so what? Getting rid of table layouts would be nice, but IE6/7 do not understand display:table either, so until IE 6 and 7 die and 8 stops trying to be backwards-compatible, they are here to stay, I'm afraid.
On Sun, Jun 20, 2010 at 2:12 PM, Tisza Gergo gtisza@gmail.com wrote:
Anyway, removing table-related attributes doesn't offer much advantage in itself. There will be a few validator warnings about it, so what? Getting rid of table layouts would be nice, but IE6/7 do not understand display:table either, so until IE 6 and 7 die and 8 stops trying to be backwards-compatible, they are here to stay, I'm afraid.
IE6 is (thanks god) dying out, one problem less... but yeah, that IE7 doesn't like display: table sucks. But why is IE8 falling back to compat-mode at Wikimedia sites? Any way to force IE8 to standard-"conforming" mode?
Marco
Marco Schuster <marco <at> harddisk.is-a-geek.org> writes:
But why is IE8 falling back to compat-mode at Wikimedia sites?
Microsoft has a blacklist for sites they deem incompatible with IE8, and Wikimedia sites are on that list (see [1]). No idea why, Wikipedia looks pretty much the same in IE7 and (non-compat-mode) IE8.
Any way to force IE8 to standard-"conforming" mode?
Yes, you can put a meta tag into the header:
<meta http-equiv="X-UA-Compatible" content="IE=edge" >
wikitech-l@lists.wikimedia.org