Knowledge talk:Manual of Style/Accessibility/Data tables tutorial/Archive 1

4004:, for example, JAWS says "Table with eleven columns and twenty-six rows" before it says "U.S. Nielsen and DVR ratings" At this point the reader is forced to manually skip to the next table where they'll hear "Table with four columns and ten rows", after which they hear "Canadian ratings". After deciding that's not the table that they want they have to manually skip to the next table again and so on. Restoring the section headings eliminates this but then there is another issue, that of heading/caption redundancy. If there is already a section heading and the first or only content in the section being a table, why is a caption needed? It's only one more thing that the reader is bombarded with. The section heading already tells you what the content of the table is, so the table caption seems redundant in this case. There are certainly a lot of cases where captions should be included ( 2639:"List of singles, with selected chart positions and certifications, showing year released and album name" is way too long. You wrote it thinking too hard about what a blind user might expect, believing that there is a significant difference between they way you and a blind person use a table. Truth is, there is not that much of a difference, at least not when the table is accessible. And you got confused because the guidelines were too vague. Instead, simply imagine that there is no section header before the table, and that you jump on the table without reading what was written above. You want a table caption, for yourself only. There are lots of possibilities. But you don't want to have a table caption that would take longer to read than figuring out the content of the table all by yourself. Here is a few possibilities: 1768:, but it's not written yet. There is a wide variety of browsers, screen sizes, and resolutions, so the problem is not the same for everyone. Personally I now have difficulty reading text on a 17" full-HD laptop without using the browser zoom, so I sympathise. I actually think that article text needs to be rendered at close to 100% as a minimum (since even 85% may be difficult for some), but it may be necessary to compromise in some cases, and 85% may be sensible target minimum for now. There's no reason why you shouldn't raise the issue with any project: I'm sure you'll be able to count on the members of WikiProject Accessibility to also discuss it and provide useful advice. -- 3858:

have to have a disclaimer saying this is incorrect structure is beyond me, the whole point was to give it a structure that could be understood by screenreaders. I am totally failing to understand why it is against advice on rowspans - the two rows spanned are both indexed to "K" so what is wrong with that? Why is it necesssary to aay in the disclaimer it might not be any use to other disabilities? I would be interested to hear what disability would have difficulty with it. The idea that it does not have semantic structure is ridiculous, great trouble was taken to ensure that every cell has a meaningful vertical and horizontal index - that was the whole point of it.

2184:

machine doesn't have any hint to understand it." is not great. I guess "red aloud" should be "read aloud" and we avoid contractions throughout. It's not clear what you mean by "doesn't have any hint to understand it" either. I guess, before suggesting this is used mainstream, it's copyedited and reviewed. Saying it's not the point of the section really misses the point. If you want people to comply with the MOS, make the MOS and its tutorials comply with the MOS.

1966:

Web accessibility is a job where you need experts to intervene in the process: someone cannot possibly jump in, read a handful of pages and claim he knows. It takes months of training to become a real expert. Sure, the basics are quite straightforward and simple, a passionated developer can learn them in a handful of days. But the approach to follow in Knowledge's case is particular because of its very nature, therefore not always documented in online resources.

4234: 39: 709:.wikitable th, .wikitable td { border-top-color: #aaaaaa; border-left-color: #aaaaaa; border-right-color: #aaaaaa; border-bottom-color: #aaaaaa; border-top-width: 1px; border-left-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-top-style: solid; border-left-style: solid; border-right-style: solid; border-bottom-style: solid; padding-top: 0.2em; padding-right: 0.2em; padding-bottom: 0.2em; padding-left: 0.2em; } 1962:"Shouldn't believe everything the guideline says" is not exactly what I meant to say. This guideline is reliable indeed. As for the definition of what is considered to be a "simple table", this guideline is vague on purpose. The interpretation of what is a "simple table" is best left to experts in this case, as they know when this technique is useful (per their feedback from users, and knowledge of assistive technologies). 1610:

improving it for those with disabilities. While I appreciate the rigour WCAG brings to that area, my background is in systems analysis and web design, and my instinct is to emphasise the problems for users who only have older technology, limited bandwidth, etc. They don't have an organisation like WCAG to advocate for their interests, so I often need to present my own research, rather than being able to point to a source.

2868:. DISCOG isn't the whole project. And rolling out changes to featured material isn't a matter for DISCOG, it's a universal issue. And you know that. So please, get your own house in order before trying to tell everyone else what to do. A half-arsed approach will just be a repeat of the alt-text nonsense, and no-one wants that, particularly as people who add good content to the Knowledge wasted a 1496:"... if the TABLE element contains no COLGROUP or COL elements, user agents should base the number of columns on what is required by the rows. The number of columns is equal to the number of columns required by the row with the most columns, including cells that span multiple columns. For any row that has fewer than this number of columns, the end of that row should be padded with empty cells." 4153:

anything as far as I know. I'm normally reluctant to display such ugly tricks to the community of editors - fearing that they may reuse the technique in a bad way. I hope that hiding the code in a template and displaying a warning that it should not be used for other purpose without approval should provide sufficient protection though. What do you say?

1046: 3945:

reader... might have a hard time. As you can see, we are not reducing the quality of contents for everyone. We keep the contents and make it accessible. It's like making video subtitles for the deaf, the content does not changes but becomes accessible. There is no point in deleting videos that does not have subtitles, what a strange idea.

974:) for the number cells may still be needed if we have cells in the column with different amounts of information in them. Otherwise, for example, '1' would line up left-aligned below '89' which looks horrible. Semantically, it's now fine (look at the page source), although it does seem a lot of effort just to make it look pretty. -- 3807:. In this case, it might be preferable to mark the years ("2000", "2001") as normal data cells, instead of row headers. The year of the single is a vague information that is not specific to the row. Thus it is not useful to mark the row as a header. But that is only a detail, and both versions are acceptable. Yours, 2283:, where a few users were claiming to be right against all. And the solution was the expert: he was the only one to have enough trust so that users will follow his advice. WP:ALT was then rewritten, and is now pretty good. Just want to point out that experts can bring something else than that Essjay controversy. 4053:

Another way to navigate to a table in JAWS is by using control+JAWS key+T to generate a list of tables on a page. (The JAWS key is either insert or capslock, depending on whether you are using a desktop or laptop keyboard layout, respectively). I'm a little surprised to find out that this feature has

2751:

common, even in featured articles (how much do you want to bet on that?). Plus some of them were not added by me, and taken directly from existing examples in the articles, so... This is kind of awkward. You should rather ask MOSBOLD if this guideline really applies to table headers, and make sure it

2472:

JPF, although I've yet to see a good example of a caption being used in the context of lists (where section headings do the job), I'm not starting this discussion again as this section was intended to address the actually very poor example of a caption that was being cited as a "good" example. And we

2361:

So, here is the answer from the expert. The examples at this tutorial are correct. Table captions may seem perfectly redundant to section headers is cases such as the DICOGS, from an average editor point of view. Table captions are fairly simple and straightforward; they are brief and efficient. They

2261:

Hmm. Complicated. I met the expert myself in real life several times, among other accessibility experts and dozens of Web quality experts (in their particular domain). This expert has a reputation to be one of the best French accessibility expert. I know other important facts about him. But last time

1741:

I assume that the profoundly blind, using text-to-speech AT, won't care about this, but users with weak vision (and I just might be talking about visitors over about 40) would probably find accessibilty enhanced if they didn't need to squint and strain so much to tell "NL" from "NZ" apart. Is this an

1672:

obviously the cells would need to all contain the relevant value, the transparent borders would just shows they match? if the transparent borders join empty cells to look like a merge without being one, that would be much worse? possibly shading neighbouring cells is a better strategy to point it out

1613:

Nevertheless, I'm convinced by your arguments that "perfection is the enemy of good enough", and I'll happily go along with making improvements incrementally. It will be a long time before more than a small proportion of Wikipedians acquire anything more than a basic understanding of the issues here,

1365:

and ask users to comply to it. It's a good practice on Web projects. For example, we decide that link are blue and underlined on mouseover and onfocus. This behavior should never change on Knowledge: it becomes a rule. It should be kind of similar with collapsible content: the appearance and behavior

3088:

Thanks Rambo's Revenge for placing tags at the top of the page that reflect correctly the issue. Could you point out some example of inconsistencies between this guideline and others, like MOS? That would really help me. Because, apart a few false claims about MOSBOLD, I don't see any inconsistency.

2980:

Take a break you two. In principle, yes the focus of this tutorial will be access based but in practice no-one will take anything seriously with glaring errors. See "1st of April to 31th of March" in the colour section, for an example. Additonally there I thought col and row spans were a problem for

2891:

If you have sensible comments to add, or relevant suggestions for improvement to share, please go ahead. But stop repeating pointlessly "Essjay controversy" and "MOSBOLD". It's completely false, you don't even know what you're talking about, and it's going us nowhere. I won't bother to reply to such

2650:

Those would be fine, it's not that complicated. Repeating the headers in the caption is redundant for blind users. If they want the main column headers read aloud, they can ask their screen reader to do so easily since the table is structured with scope="col/row". They simply want an efficient table

2395:

Didn't I told you already that I don't feel comfortable to answer this question? Even if I were to reveal his identity, it might be meaningless to you. For example, this expert is one of the authors of the French RGAA. This would mean a lot to users familiar with accessibility in France, but does it

1843:

Have you already raised this with the Usability project? It seems we're already going ahead with the 100% size in the samples in this tutorial, and it's already getting incorporated into Discographies/style, but I'm not aware if or how the Usability people are getting involved. I don't know where to

1501:

So user agents should supply empty cells (rather than failing to provide anything). Agents that conform to h-11.2.4.3 will not cause any accessibility issues specific to disabled users; but may have accessibility implications for all users of text-only agents (since they generally do not distinguish

625:

Now I'm not sure about this particular use of unbuletted lists. Sure the principle is good and all. But I'm not sure it's worth the effort here. In the "Album details" column it saves a little space. And in "Sales" and "Certifications" column it can sometimes indicate a list of two items. It's a lot

4118:

There's also the point that a caption makes a table 'self-contained' for a re-user to take just the table, but I feel that is a minor consideration compared with making life easier for visually impaired visitors. I'd recommend refining MOS:DTT to allow no captions when they would merely duplicate a

4114:

as the caption is rather redundant in those cases. However, if there is a substantial amount of introductory text between a heading and the table, then I believe that a good case can be made to use a caption, even if it duplicates the heading. How much text is 'substantial' is a judgement call, but

4078:

Thanks Graham for your valuable explanation. I was going to ask your opinion, but you answered before that. :-) Oh, by the way, I've always wondered how smileys are read in a screen reader. Do you prefer :-) or "smile" in full text? Or perhaps I could add an icon with alt text... Which one is best?

3999:

Removing the L3 headings results in an inability to navigate quickly to the table from the TOC. I have a copy of JAWS on my PC and replacement of L3 headings with table captions seems to be an issue because it takes longer to find the required table using JAWS. In the first example it's possible to

3857:

I only put the example in here because I was asked to keep a permanent record of it for future reuse. I am apalled by the intolerant attitude over this. You are making the whole thing so difficult that I am not really inclined to even try to take accessibility into account in the future. Why you

3781:

We are not promoting spanned cells, because they can easily be misused. For example, when a cell is empty in a table, users might try to merge it with a nearby cell containing a different data for aesthetic purpose. That should be avoided, because it provides wrong information to screen readers and

2614:

I'm concerned about the parallel with alt texts, which are good, except that poor alt texts are of no help. Unhelpful or over-detailed captions are visible to all, unlike bad alt texts, so I'd like at least some hint that the suggestions so far go in the right direction, even if they are idealistic

2365:

My point of view is that we may overlook table captions in discographies for now, if users dislike the redundancy. Anyway, since it's something new, we'd better begin with tables captions that benefits to everyone, and that users feel like adding because they believe it is useful for them too. So I

2290:

2.0 consists of 72 A level criteria, 28 AA level criteria and 36 AAA level criteria. And more than 300 techniques are related to them. Perhaps you can read it all in a few days, and understand it perfectly. Which would mean that you are a genius. I'm certainly not capable of that. That's why I need

1789:

I'd say this is mostly a usability issue. People with weak vision and others are technically able to zoom, so it's not really an accessibility issue. However, a surprisingly large number of users do not know how to zoom with their browser (Ctrl +/-). And for those who know, they have to zoom in and

1369:

The best solution would be to improve the script. So that it adds the "show/hide" button to the caption instead. It's a lot of work as every table using this collapsible script should be fixed (and probably manually). Still, it's definitely something we will have to do sooner or later. I believe it

593:

tags that are being used to visually mimic a list. Also, is much better than setting a td to the deprecated align=center. As usual, this isn't compulsory, but it is much better practice. The extra whitespace indenting in the unbulleted lists is only there to help make the structure clearer. I don't

3841:

as a good example. It not a perfect example, and it is in contradiction with the previous guideline about rowspans. I'm okay with leaving it in the internal guideline, but I'm going to rephrase a few lines. As it is, I fear some readers might thinks "yaaay I can make rowspans, no problem". Thanks

3014:

I do not understand your comment, Rambo's Revenge, but it seems useful and instructive. Please explain the issue with ""1st of April to 31th of March" in the colour section", it is not self-evident to me. Nor is "there I thought col and row spans were a problem for screen readers". But I'm sure it

2432:

If you want to make sure the guidelines provided by this expert are correct, please ask an expert from WebAIM (or any experienced accessibility expert) to review them. I can do that when I will be at my accessibility training too, just like I promised. But please don't go into wasteful and endless

1965:

This has always been a delicate matter on Knowledge. I met the expert in question in real life, and went to several of his conferences (where I met fellow accessibility experts). I won't tell his real identity because he doesn't want to, but I can assure you he is reliable for sure. Unfortunately,

705:

The element 'td' has a deprecated attribute 'width' which can only be a number or a percentage. The number is taken as a 'hint' for number of pixels, and the percentage is a 'hint' for the percentage of the table width. Neither of them is a good idea, and doesn't offer the flexibility of 'style',

4093:

They're read out as "colon dash right paren" by default in JAWS, but I personally have punctuation at a lower level than the default so they didn't read at all until now. I usually just scanned the text word by word if I thought there should have been an emoticon there so I could find it. But now

3886:

like to use a text-to-speech software to read tables aloud. They would use it in a different way than a very smart blind user such as Graham87. When navigating the table, they are going to ask their software what cell is related to which header, in order to lnow where they are in the table at any

3833:

I leave this information for further reference. I am thankful to Spinningspark for his dedication to find a compromise concerning table that were hard to improve. The result improves greatly accessibility. It's a step-by-step approach: we can't reach top-level accessibility right away, so we make

3551:

Colspan/Rowspan: it's best to avoid these when you can. Although, if you use it for data table and not for layout, it's okay. But only merge cells that contain the same information. Concerning headers, If you have one first row header, and several sub-row headers, you might want to use rowspan to

3377:

than "J." as it explains the abbreviation. The fact that most screen readers do not read the out loud by default (unless asked to) is an issue specific to screen readers. And most screen readers provide an preference setting to allow users to choose if they want all abbreviations to be spoken out

3175:

The expert has not allowed me to reveal his identity, he wants to remain anonymous to some extend. Like I wrote before, get another expert to review this page. If you feel the necessity, at least. There isn't any controversy worth it for now, on my point of view. But I understand that you want to

3055:

Done, thanks. The advice about rowspan/colspan does not cause any issue with most assistive technologies, and is not supposed to cause any. The advice about rowspan/colspan is supposed to be ignored. Or should I say, I wrote it because some users at the accessibility project believed there was an

2632:

The expert didn't have a look at the DISCOG captions, despite my request to do so. His English is professional, by the way. But he did say that "making a table caption is just as obvious as making section headers: it's exactly the same thing. In fact, so similar that it's instinctive, and lots of

2183:

Could I make a suggestion? If you wish to create tutorials as part of the MOS, please try to ensure they themselves meet the MOS? "Three headers are red aloud. The first and the third are correct and expected. But "Representing Soviet Union" doesn't apply to this part of the table anymore and a

1737:

What I'd like to see addressed is what minimum font-size Knowledge should be recommending or mandating. I think 85% is plenty small, thank you, considering that it's already 15% smaller than what the sighted user's preferred and expected font-size. The 75% used in the recommended examples here is

1609:

Next, there's no need for you to apologise, as vigorous debate between editors usually produces better content in the end. I should however apologise for often seeming intransigent in my own views – I didn't realise I was such a villain! You come to the issue of accessibility from a background of

4152:

However, I would prefer to keep both the headings and the table caption. Because they are both semantically correct and useful. We could visually hide redundant table captions with a style like "top:-100000px". Hiding things "left" breaks RTL compatibility, but hiding things "top" does not break

3555:

Colgroup/rowgroup scope: This code is available, and could be useful indeed... but for whom? Me, you, and some developers? We can do everything without this feature, it does not add any functionality. It only enable more efficient formatting of tables. As always, the price is an increase of code

3317:

I'm trying to establish why tooltips arrive in the "good" example. It is implied that these are part of the "good use of colors" modification, whether that's the intention or not. I don't think, unless they are explicitly discussed, they should be used in this example, as it is confusing (as I

1013:

The table given as the good example could be improved by using row headers (in this case the distances). Remember, screen readers are capable of non-linear navigation, so the ability to announce the before any cell value can be more effective when row headers are present, particularly on larger

1360:

Interesting. So the script chooses the first header and add the "show/hide" button to it. It's a pity we can't choose the header on the far right. "Show/hide" buttons are always on the right. Usability-wise it would be better to have consistent types of contents. I wish the usability team would

4031:

Before changing MOS guidelines we have to do further analysis and gather more input. Especially because there are two ways to look at this issue. The first is the one you described, where our tables might create a problem for JAWS users. The second is that JAWS may not behave is it should, and

1434:

Thanks. :-) I'm glad to be able to help. Yes, accessibility and usability projects should collaborate more. For example, the only solution to solve most of the contrast issue with colors in articles and templates is through usability. It's far too complicated for the average user to test color

1420:

Yes, one can override most global choices in their own skin css file and it's a good thing. It's very important accessibility-wise. Users can select/add a style sheet directly in their browser and have it applied for all websites (or may even be able to have website-specific style sheets). The

4115:

if we take the case of a JAWS user who revisits a page and wants to go directly to a table, we don't want them to jump to the relevant heading then have to plough through lots of text before they can reach the table. It's that inconvenience we can circumvent for JAWS users by adding a caption.

3944:

Now Graham87 uses his JAWS with specific options, and in a manner that correspond with his bright mind. He's able to grasp the structure of the table very quickly, and adapt himself. Blind people with cognitive disabilities, or multiple disabilities, or people that are new with using a screen

2802:

Bold in column headers? All of them.. Bold links? Hopefully few. Row headers? Hopefully very few. I think DISCOGSTYLE has been led astray by ACCESS and you know it. Point me to a featured list that has been promoted within the last year with a bold link in it. I challenge you. Go on.

3652:

Thanks for responding. I haven't seen any of these edits since around the time I posted the original message here. I should have added diffs at the time; they have long fallen off my watchlist and out of my short memory. I can't honestly think of a compelling reason to introduce it into most

2428:

in the U.S. Except that the RGAA applies specifically to Websites. It is enforced by the French State. The expert I'm in contact with has enough trust and recognized expertise that he could be one of the authors of such an important application methodology of WCAG 2.0. This expert is also an

3621:"plainrowheaders" only affect the layout. It makes row headers look "plain", more like a normal cell, so it doesn't stand out. "plainrowheaders" is not necessary, but it's also harmless. Adding it with AWB might add more consistency, but might also displease users that like bold row headers. 3011:@The Rambling Man: Graham87 was able to copyedit without placing a "disputed" tag, hopefully. The Rambling Man, you're really not helping me. I know you have good faith and all, but a real troll would help me just as much as you do now. Take a break or whatever, but stop focusing on details. 2557:

is an expert, but the account is anonymous and will forever be. I've been patient enough with you. I've told you about the expert being an author of the renown RGAA. I've suggested to contact other experts. But you don't even care about my replies. Unless you change your attitude and become

2654:

In cases where the table is hard to understand visually for sighted users too, table captions may become slightly more descriptive to fit the needs. But again it's trivial, and you'll know it yourself when the table caption is not descriptive enough or instead not concise enough. Yours,

2477:

the parallel to alt text. No-one disputed alt text is a good idea, we just had "expert" advice there, the MOS changed, FLC and FAC were mandated to use it, then the advice turned out to be a crock. So little wonder people are overly cautious when these sort of things are rolled out.

4058:! Each table is labelled by its caption or by the column headers if a caption is not present, so the captions do help a screen reader user to navigate the tables that way. However the TOC method probably works with more screen readers; there is no keystroke to make a list of tables in 2960:

Improve the column widths yourself if you feel like it. I would have done it when I would have planned the change with the corresponding project, anyway. But there is no emergency to do it now. If you feel like working on this trivial detail, you're mature enough to do it yourself.

1431:"I'm somewhat colour-blind between the default blue link and the default for a visited link": as many of us average users. The usability team received a lot of complaints about it. But strangely - especially for a usability team - they did not take this feedback into account. WTF? 3912:

Why will any of those groups have more difficulty reading my example table than any other table? My table is specifically designed so that the software correctly reads "what cell is related to which header", that was the whole point of it. Why do I have to keep remaking this

3727:

Interesting question indeed. :-) Fortunately there is another way. I would add a column "year", and place it as the first column. Thus, years like "2000" can be set as row headers spanned across several rows. The "years" column can be sortable too, thus it even improves your

2121:" is considered to be "good". I would argue this is completely incorrect, how does that caption help a reader understand the content of the table he or she is about to read? Also, can I just get confirmation that screen-readers and visually impaired readers would have the 1958:

Thanks for coming here. Such discussions in "public" are going too fast compared to the time we need to get an answer from an expert. And the editors tend to lose faith in accessibility guidelines quickly in such cases. It's always harder to rebuild the faith once again

3948:

Sorry about the mention of dyslexia, that was stupid from me. I wrote this answer in a hurry this morning and I made a mistake. :D I was thinking about people who have trouble to identify the way things are organized and structured, which is rather related to cognitive

4133:

I would support your suggestion. The criterion of substantial text is a good guideline for editorial judgement. I would be happy to eliminate redundant captions where there are already section headers, I have had a few tiffs with editors about this point in the past.

3978:

There seems to be an increasing use of table captions in compliance with MOS:DTT, but which seem to be causing more problems than they fix. For example, in TV season articles it's common to have a "Ratings" section with multiple tables laid out something like this:

1581:

I'd like to apologize for my rudeness a few weeks ago. I did not realize you were willing to compromise on this issue. I appreciate your participation and comments. And I'm looking forward to work with you in this accessibility project. :-) Again, please accept my

3940:

Let me explain. It is true that the long description is under the header "Extended comments". But at the same time, it is a cell spanned under several other headers ("Maker", "No.", "Owner", "Type", "Winding", "Comments"). This cell has 7 headers, and only one is

1620:

I've commented at the Discographies style page, and I'm encouraged by the reception you've had there. Let me know when you approach other projects, and I'll do my best to help and to mobilise folks like Jack (who is clueful and has his heart in the right place).

2380:

Sorry, perhaps you missed my question which was "how expert is te expert?" And why should I believe what you're saying that he's saying is correct? Captions for most tables in these lists are pointless right now, but that's not the main thrust of my concern.

3673:

According to the description of events you are reporting, it might have been applied to a set of articles within a wikiproject. If decided by a wikiproject, that might be perfectly in the intent of "plainrowheaders". It's only a hypothesis though. Yours,

3176:

prevent issues. Then get another expert to review the page, one that allows to publish his name. Contact WebAIM. I won't do it for you. I'm not your personal secretary and I'm not supposed to work hard trying to fix every small issue that you bring up.

3056:

issue with rowspan/colspan. I wrote it to explicitly say: the issue with rowspan/colspan is negligible, and not considered to be an issue by WCAG 2.0. Any attempt to remove rowspan/colspan will be refused by users anyway, so it's not even worth trying.

2040:

As for the sudden reply at the FL discussion: I'm sorry, I didn't expected the expert to reply that quickly. As for the details of this discussion, it is best to keep them here as my detailed reply will be fairly complex for non-technical users. Yours,

1546:). For example, I believe that Lynx conforms to UAAG as much as IE8 does, yet the rowspan vs empty cell problem demonstrably exists with Lynx. You may need to distinguish between graphical browsers and text-only browsers to give meaningful advice. -- 3653:

articles. It seems to me that it might help if there is a lot of text in the headers, and bolding them causes the font to be larger than usual? Otherwise, I would think that bolded row headers slightly aid in distinguishing them from data cells.

3071: 2863:

Please make sure any "example" of captions for "data tables" etc you provide is fully MOS-compliant. Then there'll be no more problems. And let us know how "expert" this "expert" is, and then we'll start believing you. Don't give us another

2673:

is a good enough example of table captions, albeit arguably not perfect. "US overall university rankings" might be better, but it would be too large for the infobox width, so it's OK. I'm pointing it out because I just fixed it today. Yours,

2817:

No, you're right. All infoboxes have bold links, and the guidelines suggest that that's just fine for a "caption". Well done MOS. It looks pitiful, but no reason to bend to the aesthetic appeal of 99% of our viewers in favour of no-one.

1785:

I already had to fight this issue several times on french wikis. Several users love small text and it's a pain to deal with this issue. That's why I hesitated to bring it up. But since we agree on that it might be worth trying to solve this

2510:

I said "overly cautious", not "overly suspicious", and there's a huge difference. You need to prove this expert is worth listening to and has suitable qualifications. This is going to become another drama unless we get an open discussion.

2168:

has no link and the alt text is blank. Since the useful information follows the icon flag, there is no loss of information here. This template is compliant to accessibility guidelines. Thanks for your interest in these matters. :-) Yours,

3187:), to have a third party review the page. But you don't even care about my replies, and you keep asking the same question, over and over again. Unless you change your attitude and become cooperative, I won't discuss with you any further. 3529:" for those merged headers. It seems a good idea to mention that here somewhere to get this as accurate as possible. Now if we shouldn't be using merged headers, then none of what I've just typed means much and everyone can ignore this. 1401:

Similarly, anyone can override default behaviour for classes, such as the class="db-ZXh0ZXJuYWwgdA" to change the style of external links only. Of course, all of this works as simply as that, only if we don't embed in-line styles in

4269: 3381:

Concerning their presence in this tutorial, they are not needed. Abbreviations are low priority, and are not the subject of this tutorial. They can be removed if it appears that is confuses editors (as The Rambling Man suggests).

1405:

You've made a lot of progress with giving good accessibility advice here, and all of it will also be useful for those working on the usability project – good accessibility and good usability have a habit of going together. Cheers

74: 1821:

Since this issue is mostly interesting from an usability point of view, I suggest to bring this issue at the usability project first. Let's make a guideline about readability there. And afterward I suggest to bring the issue to

1435:

contrasts with the Color Contrast Analyzer and corresponding guidelines. It's easier to decide that "for usability reasons the colors used in Navbox should be ... (insert relevant choice here) and that rule should never change".

97:

which might be useful when tables become wide. It produces the correct semantic markup for a list, which is exactly what is needed when a data cell contains a lower hierarchy of data (in this case a list). Here's an example:

3921:

have a problem with tables). Everything would have to be written to the lowest common denominator. We would end up with something like Simple Knowledge - making that project superfluous and Knowledge infinitely less rich.

3670:"Plainrowheaders" was created for users who refused to make row headers because of the bold. And this strategy was successful, these editors started to make row headers with "plainrowheaders". It improved accessibility. :-) 4148:

Just like Elizium23, I support RexxS proposal. I recall several heated discussions about table captions redundant with headings. Editors are reluctant to create redundancies, thus it is an obstacle to the adoption of this

3916:

The idea that we need to structure articles for the benefit of people with dyslexia and memory problems utterly horrifies me. Tables would be the least of the problems here (and I am still failing to understand why they

4167:

I don't really see any problem with including a table caption when there is any text between the heading and the table, even one or two sentences seems "substantial" enough in most cases. An editor recently went through

2927:

Go trolling elsewhere. This tutorial is about accessibility, not layout. We can sure improve the layout, but it's not the main concern of this tutorial. Am I clear enough? You sure know how to make a fuss about details.

1952: 1538:"Old screen readers and user agents that do not conform to UAAG do not handle rowspan / colspan efficiently. The result can be very confusing for users of these technologies." - this seems to imply that user agents that 992:

We'll use more code if necessary. But I would be best to choose this option only as a last resort. For the numbers of the second row a non-breakable space "& nbsp;" produces the same result. Is it better? Regards,

3050: 2025: 4008:

is one) but there are cases where they're unnecessary, and in some cases detrimental to improving accessibility. I think this needs to be pointed out in the MOS, as a lot of editors believe that they're mandatory.

3385:

Using three-letter month abbreviations is indeed a good solution, when there is enough space to allow it. But even then, it should still be marked as an abbreviation. For example, {{abbr|Jan.|January}} produces

2222:

I've just asked the French expert at fr.wiki to provide details about table captions, and their content. I aasked him the especially review the discography cases, and this tutorial. Let's see what his answer

25: 1987:

is mistaken on this particular detail. Reliance on the "simple table" criteria is creating various problems, including in assistive technologies. And it doesn't comply to other related WCAG 2.0 guidelines.

4032:

perhaps it should spek the table header first. Or provide an easier way to navigate tables. Maybe other screen readers are better at this. Who knows, there might be more things to take into account here.

3603:. I was rather surprised to find no mention of plainrowheaders in the tutorial, so I am wondering if this is a valid rationale for AWB to be adding them, and what exactly it is fixing or extending here? 2887:

What turns out to be a crock is your constant false claims about MOSBLOD. I'm dead sick of that. Do you have some kind of bold phobia? Seems like you have much more to understand about MOS criteria than

2433:

debates about the Essjay controversy. You don't have any facts that can prove this expert is a fake anyway, every guideline a my table tutorial is referenced by the W3C and WebAIM after all. ;-) Yours,

2247:

Perhaps it needs another copyedit by someone familiar with the rest of the MOS. I think most of us want to understand what makes the expert the expert. As you know, we don't want another Essjay saga.

2108: 3409:

It seems this is used indiscriminately throughout this "tutorial" without any advice as to why or how. It needs to be discussed otherwise the unbold scoped row headers will be confusing to users.

1029:

In theory I agree of course. In this particular case I was unsure the distance would made relevant row headers. But at a second thought – and after I saw more use cases – I think you are right. :-)

3778:

support it since 2005. It is true that some seldom used software does not support spanned cells, but it is their fault for not being up-to-date. So spanned cells is not a problem for accessibility.

3283:

element unless the user asks it to do so. Unfortunately, it also gives no indication that there is a tooltip. IMO use of the abbr element is harmless, but not usually benificial, for JAWS users.

3037:

section above (you even commented there). The second supposedly good table uses col spans. This is why things need to be consistent. Advice in one part of the tutorial is ignored in other tables.

2366:

will being with some templates, and other kind of uses for those table captions. Maybe later on users will get used to it, and will add them spontaneously to the DISCOGs. Time will tell. Yours,

1391:

file. For example, I like to be able to pick out recently visited pages on my watchlist, but I'm somewhat colour-blind between the default blue link and the default for a visited link, so I set

1990:

It's the second time I've seen such a mistake. I'll report the mistake to the corresponding working group of the WCAG like I did last time, and start a discussion at their mailing list. Yours,

3804: 3732: 2496:

before it became a public issue. And we weren't able to prevent the drama. So this drama should not discredit us, because we were right. Being overly suspicious is not helpful either. Yours,

3485:. It appears to me you managed to solve your problem in the meantime, isn't it? However, if you still need assistance, or if you have questions about accessibility, feel free to ask. Yours, 2034:

approach, for sure. But it is not supposed to be applied blindly by someone who is not familiar with the process. We're not writing an article here, we're deciding our site-wide guidelines.

1428:

Still, the default appearance should not change. When users customize style sheets it's their responsibility and choice (and needs). The default appearance should be consistent nonetheless.

3303:. Actually in the case of monthly tables, using Jan, Feb, etc. could be a better practice for everybody ? BTW is it a common practice to get negative examples of articles in a tutorial? -- 2788:

have bold links in the column headers, most infoboxes does too, and so on. If MOSBOLD does not allow bold links it table headers, as a matter of fact MOSBOLD is ignored everywhere. Yours,

1765: 3183:

I did provide this reply several times now. I've been patient enough with you. I've told you about the expert being an author of the renown RGAA. I've suggested to contact other experts (

2733:

to comply with MOS. Access changes MOS, we have to comply with it. Access turns out to be in contradiction with MOS itself. Problem. Work it out before enforcing it on the community.

2079:, like Euracert and the French RGAA says the same. They all agree that W3C made a slight mistake here, and this mistake is likely to be fixed in later versions of the WCAG 2.0 guideline. 671:

At a second thought, the widths are set to create a cellpadding. And ems doesn't work in the width attribute. Maybe the % would be a good solution but I'm not sure. Is there a reason why

1542:

conform to UAAG don't have problems with rowspan/colspan. Since I don't think any user agent fully conforms to UAAG, what are we saying? This opinion is reflected in Knowledge already (

2997:

Agreed. All I ask if for a "MOS tutorial" to comply wholesale with "MOS", not just the bits it wants to. Lazy. Especially when projects use this "tutorial" as "gospel". Night all.

2410:

So it's a concern that you're modifying style guides under the guidance of someone who claims to be an expert whose identity and qualifications will remain a mystery to the community.

3749:

That seems like a good idea. Thanks a lot for the suggestion – I'll start implementing it into some of the lists that I update. So cells that span over several rows are allowed under

3705: 3083: 3065: 2636:

In short, yes. Don't blame yourself though, it's my responsibility for not having anticipated this issue, and not having enough time to address every issues that popped up recently.

2492:

Just like I told you, discographies may not the best place to begin using table captions. And for the record, the accessibility expert in question and I were aware of the issues at

2050: 1978: 1660:

Does using transparent borders instead of merging make it better or worse? That can give the same aesthetic, but without navigation issues for those who are not navigating visually?

2770:

of MOS. I don't need to ask MOSBOLD anything, it's there, it's a guideline that we've been following for years. And now, in your "good" example, you break the MOS. You choose.

2429:

accessibility trainer. Is that enough? There is much more to tell, but I don't want to get into the details, otherwise it would be a direct violation to his right to be anonymous.

2291:

to be in contact with an expert. I'm doing my best, I'm using accurate sources, but I still need an expert to ensure I'm doing the right thing. Hope that makes it clearer. Yours,

1585:

Are you okay with the content of this section? If you still disagree on something it's time to bring up the issue. Or if you would like to rephrase a few paragraphs, go ahead. :-)

3168:

So you want published evidence that an anonymous user account is owned by an expert? Impossible, Wikimedia does not make such authentications. I have any number of proofs that

2553:

So you want published evidence that an anonymous user account is owned by an expert? Impossible, Wikimedia does not make such authentications. I have any number of proofs that

2305:

I don't think I ever questioned the need for an expert, but it's fair enough for the community to ensure that the "expert" advice is really coming from an "expert". Cheers,

2525:

So the expert being an author of the French RGAA is not enough in your opinion? And you won't even contact an expert yourself to fond out by yourself? What do you wish for?

2146:

Sure, the captions there can be improved. It wasn't the point of the section, so I didn't pay too much attention to it. I'd say "Vasiliy Kaptyukh achievements representing

630:

contains a few examples where unbuletted lists would really be useful (lists of 4 to 7 items). It needs some more thoughts (and possibly feedback from users) on my opinion.

2607:

It's not clear to me whether that's your phrase or the expert's, or whether that's a philosophical, general statement or an analysis of some specific captions. Is the

1829:

Usability and accessibility have a lot in common, and I believe this topic is an great occasion to improve the collaboration between these two projects. Kind regards,

3771:

Yes, spanned cells are allowed when they are merging cells that contains exactly the same data. Instead of repeating 12 times "2000" we can merge them into one cell.

2269:(7 to 10 December), where 5 accessibility experts are present. And this time, they are listed and can be precisely identified through the links provided on the page. 3667:

OK. I agree with you, as I also like to distinguish row headers from data cells. And I would not encourage to blindly add "plainrowheaders" to each and every table.

3089:

Of course, I haven't read most MOS guidelines, and I'm only "en-3" - not a native speaker. Still, no matter how hard I think, I don't see any evident issue. Yours,

2981:

screen readers. If what you offer looks worse (even if it is more accessible) people won't warm to it. My advice, take dispute tags etc. as constructive criticism.

3599:

I have noticed recent edits by AWB that are adding "plainrowheaders" to the preamble class="db-d2lraXRhYmxl" on tables, and the edit summaries pointed me here to

1589: 2319:

Fair enough indeed. I can't provide the identity of this expert, but I can provide the identity of the experts I will meet at the accessibility training. Yours,

712:

Since that applies to each cell, it overrides the value "inherited" from a cellpadding attribute in the table element. The best I can suggest is to either apply

21: 3708:? Dividing up the table here would mean sacrificing the ability to sort within the entire decade. What's the standard practice in cases like this? Thanks, 2836:, promoted in March 3, 2009. Just so you know, the accessibility project entered in contact with the DISCOG in september 2010. I'm going to sleep, see ya! 3879:

I did not meant to discourage you. I wanted to find a more thoughful way to do this, but I did not manage. I'm human, and I failed here. Sorry about that.

1931:

that maybe I shouldn't believe everything the guideline says, and that this has been "reviewed by an accessibility expert". Forgive my sceptisim, but the

1721:

I spend a lot of my time fiddling with music articles, which means I work a lot with discography tables as used in the examples here (no doubt taken from

4176:. (Column widths are an issue for articles being nominated for "Featured" status.) He also added captions to the episode tables, which is appropriate at 2346:

Well it's just about getting the confidence of the community. We're not trying to trick you, we just want to understand how "expert" this "expert" is.

1617:

The content is fine, by the way. Nothing on Knowledge is a finished work, and I expect others will eventually refine and improve what you have started.

1823: 1743: 1438:

Also, did you notice how I make the navigation in this Wikiproject? I used two usability recommendations that are almost never used on Knowledge: a

3477:

Sorry for not having replied earlier, I was on a break and did not see your message. There should normally not be any kind of problem while mixing

4211: 4162: 4143: 4128: 4105: 4088: 4073: 4044: 4022: 3961: 3935: 3907: 3874: 3851: 3816: 3798: 3766: 3744: 3721: 3683: 3662: 3647: 3633: 3612: 3583: 3565: 3542: 3494: 3471: 3433: 3418: 3399: 3343: 3327: 3312: 3294: 3277: 3259: 3236: 3210: 3196: 3162: 3126: 3112: 3098: 3024: 3006: 2970: 2955: 2937: 2921: 2901: 2881: 2845: 2827: 2812: 2797: 2779: 2761: 2742: 2724: 2709: 2683: 2664: 2627: 2567: 2548: 2534: 2520: 2505: 2487: 2467: 2442: 2419: 2405: 2390: 2375: 2355: 2328: 2314: 2300: 2256: 2242: 2214: 2200: 2178: 2140: 2088: 1999: 1896: 1878: 1860: 1838: 1777: 1758: 1711: 1684: 1647: 1630: 1601: 1570: 1555: 1525: 1511: 1483: 1455: 1415: 1379: 1354: 1061: 1038: 1023: 1002: 983: 695: 664: 603: 594:

expect every editor to cope with this sort of markup, but there's no reason why experienced editors can't improve this as they clean-up tables. --

3774:

Concerning accessibility, most screen readers and accessibility-related tools support spanned cells. For example, the most popular screen reader

2912:

So a good example actually makes the column widths differ from section to section? It may be accessible but it looks awful to regular viewers.

2700:

So now you have bold links in your "good caption" which seems to contravene MOSBOLD. Please work this out before you tell us to comply with it.

4062:, for example. It would theoretically be best to allow for both methods of navigation, but that would introduce redundancy, as discussed above. 1729:

for the column headings. The setting of 75% for the font-size is widespread among the music articles, and (or because) it closely simulates the

3762: 3717: 2670: 737: 355: 119: 3700:

Removing column headers that span several rows by dividing the list into smaller tables, each with its own caption header, makes sense in the

1699:. It is definitely a good idea that should be adopted somehow. How do we gather consensus? Should we make a request for comment or something? 3704:

listed on this page. But what is the protocol when it is necessary for the table to remain as one for sorting purposes, as in, for example,

4173: 3899: 3457: 2600:? Did he have any statement to make about the length or approach of these specific examples (assuming the expert has some English fluency)? 1884: 3378:

loud by default or not. Of course it's not perfect. But it's not perfect today, and screen readers might find a better solution later on.

2362:

are not redundant from a semantic and accessibility point of view, however. And nothing is able to compensate the lack of a table caption.

2055:

This guideline has it wrong, and it's a known fact to accessibility experts. See, there are several application methodology for WCAG 2.0.

655:

for example. I'd rather work on a large-scale important improvement on Navbox than a few lists here and there. Priorities, priorites. ;-)

1923:"For simple tables that have the headers in the first row or column then it is sufficient to simply use the TH elements without scope." ( 2037:

I've just send you an e-mail with the copy of the previous exchange I had with the WCAG working group, to show you how it works there.

1702:

Note that I implemented this suggestion on the french Knowledge the 22th of August, following Jack Marridev's good proposal. Regards,

3103:

If no valid example of inconsistency with other guidelines is provided in a few days, I will remove the tags at the top of the page.

1673:

visually without causing screen reader problems? though, i have heard, some sighted people find too much colour kind of disorienting.

1669:- or is the kind of flagging of "this run of cells all have the same value" less relevant to someone navigating through cell by cell? 3227:

which states "Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text."?

3861:

Frankly, you may as well delete the whole thing, it isn't worth shit without a code example to explain how to actually achieve it.

716:

to each cell that requires padding, or to apply it to each row if you want it throughout the table. Example on a 'per-cell' basis:

4110:

Ever since Graham told me that he finds it quicker to use headings than captions, I've been advising editors not to use captions

3268:

use tooltips/hover tips etc seems strange in light of the example which moves from plain text to text with tooltips/hover tips.

1803: 3556:

complexity for 99% of users. Our users are already leaving because of this issue, and I'm not going to make this worse. Yours,

1866: 1845: 1370:

would be better to gain experience with other simpler tasks. And afterwards we should make a task force for this job. Regards,

3264:

Okay, so this is a little confusing because the screen reader will read JFM etc without the tooltips. The guidance saying to

1384:

If we could ensure every table had a caption, then it would be the perfect place for the show/hide trigger. One day, maybe ...

4250: 4185: 4181: 4177: 3117:

Just like I thought, there is no valid examples of inconsistencies. Only false claims about MOSBOLD. I'll remove these tags.

2642:"The Prodigy singles and peak charts"; "peak charts" are relevant in the caption because it is the main content of the table. 2473:

all know what happens when we "accept expert advice" from mysterious experts whose identity and qualifications are unknown.

55: 17: 2272:

I can ask them any question you want, any accessibility issue you want to raise. And I'll get back at you with their answer.

3513:". I've also noticed in looking at the source material that when setting the scope of a header, not only can it be set to " 3373:

template is using the semantic tag "abbr" that was specifically made to improve accessibility. It is always better to have

592:

have them, use ems because you don't know the metrics of the client's browser font) as well as the deprecated <br /: -->

4001: 3882:

Concerning people with disabilities that would have trouble using this table. Sighted people with cognitive impairements,

2205:

I've now added a disputed tag because it appears my concerns have been read but not addressed or responded to. Cheers.

4055: 2747:

I have the feeling that you are following MOS rules more strictly than it is intended to be. Links in table headers are

1764:

It's certainly an accessibility issue and the Accessibility Manual of Style should give guidance. The place would be at

1592:

accordingly? That way we will be able to move forward, and do the same thing with other WikiProjects. :-) Kind regards,

1543: 2833: 4184:, even though though the season 4 article includes only two lines at 1280px width. The table caption is redundant at 4000:

jump directly to the table, while in the second it's necessary for JAWS to read each table's header information. At

3043: 2987: 2018: 1945: 1635:

Very interesting answer. I wanted to provide a detailed answer a long ago, but that answer was too long to write. :D

4241: 3758: 3713: 3414: 3323: 3273: 3232: 3206: 3158: 3070:

I intended to move those guidelines to a dedicated page to prevent such confusions a long time ago. It's now done:

3002: 2951: 2917: 2877: 2823: 2808: 2775: 2738: 2705: 2622: 2544: 2516: 2483: 2462: 2415: 2386: 2351: 2310: 2252: 2210: 2196: 2136: 1855: 1753: 46: 3898:

Now, your efforts are appreciated, as you are going in the right direction. Please don't give up. Yours, Dodoïste

3223:

Why does this "tutorial" include information that you only see if you "hover" over it, in direct contravention of

1797:. Usability guidelines recommend a default font size of at least 12 points (about 16 pixels, but pixels are evil). 3456:. Is there a way around this? In case my explanation is as clear as mud, the table I was trying to change was in 3424:

Sure, will do. I did not find it necessary at the moment. But seeing the questions below it is necessary indeed.

2715:

Relax a bit with MOS bold rules, will you? We solved all the bold issues so far, so this is becoming routine. :D

2072: 2009: 1387:

Incidentally, my links are whatever colour I want, as anyone can override most global style choices in their own

1561:

That's right, thanks for reporting this issue. I'll take it into account when I will complete this section. :-)

4059: 4028:

You have a good point AussieLegend, thanks for having spent this much effort to bring valuable information. :-)

3952:

Anyway, I hope you understand better now, and that we will be able to improve our understanding of each other.

3903: 3579: 3246:. A screen reader will then read correctly the months abbreviated into a letter (JFMAMJJASOND). The use of the 1638:

At any rate, this guideline is currently being reviewed. It will be ready to be implemented in a few days. :-)

91: 2279:

guys, as what was did concerning alt text and what led to he change needed. See, there was a huge issue with

4204: 4015: 3929: 3868: 1443: 627: 706:

although having a single definition of padding is convenient. Padding is defined in the 'wikitable' class:

3466: 1446:

items. How about we organize help pages like that? It would surely make it easier for newcomers. Regards,

682:

If cellpadding are used it also solves the issue with centered text as text becomes centered by default:

87:

At the risk of increasing the number of templates in an article, there is a space-saving template called

3888: 3754: 3709: 3410: 3319: 3269: 3228: 3202: 3154: 3038: 2998: 2982: 2947: 2913: 2873: 2819: 2804: 2785: 2771: 2734: 2701: 2618: 2593: 2540: 2512: 2479: 2458: 2411: 2382: 2347: 2306: 2248: 2206: 2192: 2132: 2013: 1940: 1851: 1749: 1722: 1663:

The catch would be, it means whatever point the merge is showing is not available to non visual readers?

4158: 4084: 4040: 3957: 3847: 3812: 3794: 3740: 3679: 3643: 3629: 3561: 3490: 3429: 3395: 3192: 3122: 3108: 3094: 3079: 3061: 3020: 2966: 2933: 2897: 2841: 2793: 2757: 2720: 2679: 2660: 2563: 2530: 2501: 2438: 2401: 2371: 2324: 2296: 2238: 2174: 2084: 2046: 1995: 1974: 1892: 1874: 1834: 1707: 1643: 1597: 1566: 1521: 1479: 1451: 1375: 1057: 1034: 998: 691: 660: 2645:"List of The Prodigy singles" would be OK too, but "List of" may well be self-evident and unnecessary. 3892: 3332:(EC) Using three-letter month abbreviations and removing the tooltips sounds like a good idea to me. 1983:

The accessibility expert replied to my mail. I'll detail it further this evening. But it turns out,

1969:

As promised I just sent an e-mail to the expert, to have further explanations on the matter. Yours,

1474:. Is it an accessibility issue? Does it makes the table confusing for screen reader users? Regards, 4169: 4139: 3658: 3608: 3575: 3537: 2597: 4200: 4100: 4068: 4011: 3924: 3863: 3338: 3289: 3150: 2865: 2784:

Right. How many featured lists comply to the bold links in the column headers for discographies?

1932: 1984: 1920: 1814: 1800:

There is any number of useful resource about readability on the Web. But those three stand out:

611:

I do agree about the widths. Widths do make the table look prettier. But they should be made of

4188:, but use of the caption is consistent with the five other season articles, so even the use of 2266: 3461: 3169: 2554: 2219:

The tutorial was reviewed, and copyedited mostly by Graham87 whom I thanks for his great help.

1680: 1614:

and I accept that we need to "sell" these ideas slowly enough that we don't provoke rejection.

1425:

is made especially for this purpose: it overrides the website's style sheet and inline styles.

639: 4094:

I've added ":)" and ":-)" to the JAWS dictionary manager, so they both read out as "smiley".

2076: 1490: 4154: 4080: 4036: 3953: 3843: 3808: 3790: 3785:

In conclusion: we should remain cautious about using spanned cells, but it is allowed under

3736: 3675: 3639: 3625: 3557: 3486: 3425: 3391: 3308: 3255: 3224: 3188: 3118: 3104: 3090: 3075: 3057: 3016: 2962: 2929: 2893: 2837: 2789: 2753: 2716: 2675: 2656: 2559: 2526: 2497: 2434: 2397: 2367: 2320: 2292: 2234: 2170: 2080: 2042: 1991: 1970: 1888: 1870: 1830: 1793:

Small text affects readability a lot, and has been thoroughly studied by usability experts:

1703: 1639: 1593: 1562: 1517: 1475: 1447: 1371: 1053: 1030: 994: 823: 687: 656: 441: 204: 2633:

Knowledge users have been doing it successfully for years relying on their instinct alone".

1606:

First of all, let me say that you've done an excellent job here, and it's much appreciated.

4124: 1808: 1773: 1626: 1551: 1507: 1411: 1350: 1019: 979: 789: 649: 615:

rather than pixels. A good practice that I forgot to apply here. Thanks for reporting. :-)

599: 407: 171: 1422: 2872:

of time complying with the advice of an "expert" who turned out to be a crock. See ya.

4135: 3654: 3604: 3530: 797: 415: 179: 4192: 4096: 4064: 3600: 3592: 3367: 3334: 3285: 2493: 2280: 2187:

Also, in the "good" example, col widths change from table to table, which is clearly

744: 362: 126: 3571: 1935:

now makes me cautious over matters like this. I'd much prefer to see something in a

1742:

appropriate place to address this? Or am I better off pursuing my little crusade at

3505:

I've noticed there's not really any mention of the use of merged headers in using "

2605:

Table captions are fairly simple and straightforward; they are brief and efficient.

2162: 2150: 2125: 2115: 2005: 1936: 1794: 1676: 819: 437: 200: 3072:

Knowledge:Manual of Style (accessibility)/Data tables tutorial/Internal guidelines

4198:

in that article seems "substantial enough" text to justify use of the caption. --

3638:

I have added a section about layout and plainrowheaders in the tutorial. Cheers,

2068: 1869:. Well, I'm not sure they are really active right now. But it's worth a try. :-) 4249:

If you wish to start a new discussion or revive an old one, please do so on the

3304: 3251: 2425: 2056: 891: 784: 769: 764: 749: 509: 402: 387: 382: 367: 270: 166: 151: 146: 131: 54:

If you wish to start a new discussion or revive an old one, please do so on the

4120: 3149:

Please specify the expert and his relevant experience. We don't want another

1769: 1622: 1547: 1503: 1439: 1407: 1346: 1015: 975: 595: 2233:

This is my last edit until tomorrow evening, I'm going to bed. Kind regards,

1442:, links in the menu are organized in sub-menus that do not contain more than 3989:

In order to comply with MOS:DTT, articles are being changed to this format:

2060: 1470:

In several tables cells are not created when they should be blank. Example:

1206: 878: 496: 258: 3282:

In the case of JAWS, it won't expand the abbreviations in the <abbr: -->

2832:(way too many edit conflicts) It took me 20 seconds. The first FL I found: 1885:

Knowledge talk:WikiProject Usability#Readability issues and small text size

3570:

Colgroup and rowgroup are required to make complex tables accessible. See

3982:== Ratings == === U.S. ratings === <ratings table without caption: --> 3444:

I tried to edit a table to include the "scope" parameters. The table has

3172:

is an expert, but the Knowledge account is anonymous and will forever be.

2946:

correct otherwise it should not be part of the MOS. Am I clear enough?

2451:

Well, TMR, if we accept what the expert says, and IIUC, the captions are

1915:

I don't want to get into a long debate over this and it has already been

827: 445: 208: 4172:

season articles, adjusting column widths so they'd appear consistent in

2539:

Evidence. Published evidence so we can all see it. It's very simple.

3786: 3750: 3701: 3618:

Sorry for the long wait. I was on a break and did not see your message.

3548:

Sorry for the long wait. I was on a break and did not see your message.

1575:

I tried my best to reword this sentence. Is it okay or still confusing?

1544:

Web Accessibility Initiative#User Agent Accessibility Guidelines (UAAG)

810: 759: 754: 428: 377: 372: 191: 141: 136: 4005: 3184: 2276: 2064: 1578:

Now this tutorial is complete. I will ask an expert to review it. :-)

1275: 779: 774: 397: 392: 161: 156: 4035:

I'll ask other to share their opinions on the matter. Thanks again.

2752:

does apply in this context before asking us to comply to it. Yours,

1790:

out just for these table headers. It's a pain, and it's unnecessary.

588:

This also removes some of the the superfluous column widths (if you

2611:

here a condemnation of the 15-word captions I've been implementing?

3448:, and two of its five columns are unsortable. I found that adding 1697:

request on MediaWiki talk:Common.css to improve the default layout

3984:=== Australian ratings === <ratings table without caption: --> 2592:

Dodoïste, did the expert take a look at the specific captions at

2262:

I mentioned his identity and expertise, he didn't appreciated it.

4112:

where they would duplicate a heading immediately above the table

3992:== Ratings == <ratings table with caption "U.S. ratings": --> 3775: 2287: 2031: 989:

Thanks for the information about padding in the wikitable class.

3983:=== Canadian ratings === <ratings table without caption: --> 3895:, I've worked with people with a lot of different disabilities. 2111:

of the tutorial, it is claimed that a caption of "Representing

1362: 4228: 3177: 1766:

Knowledge:WikiProject Accessibility/Manual of Style draft#Text

33: 1590:

Knowledge talk:WikiProject Discographies/style#Time to update

3985:=== U.K. ratings === <ratings table without caption: --> 3887:

given time. And that's only 2 cases, there are people with

3805:

Talk:List of Hot 100 number-one singles of the 2000s (U.S.)

3733:

Talk:List of Hot 100 number-one singles of the 2000s (U.S.)

3803:

I made a slight change about the new table I suggested at

2191:

good for sighted viewers. I suggest that's modified too.

2069:"The scope attribute should be used on simple data tables" 1734:

that was the typical formatting before the CSS got added.

1725:). This example (in both the "good" and "bad" cases) uses 1074:

Collapsible tables can also work without the faux header:

3624:

Could you provide links to the edits you mention? Yours,

3994:<ratings table with caption "Australian ratings": --> 3242:

The mouseover effect comes from the use of the html tag

1588:

If you agree with this compromise, could you comment on

679:? Cellpadding would definitely be the simplest solution. 3838: 3360: 2227: 1928: 1916: 1696: 1471: 3993:<ratings table with caption "Canadian ratings": --> 3706:

List of Hot 100 number-one singles of the 2000s (U.S.)

3015:

will be constructive, so please provide details. :-)

2942:

No, this is a data table tutorial. It has to get it

1076: 2012:

over some editor I know nothing about (no offense).

635:

Among tables, there are some far more urgent use of

2558:cooperative, I won't discuss with you any further. 718: 336: 100: 4119:heading just before the table. Hope that helps, -- 3995:<ratings table with caption "U.K. ratings": --> 3884:or users with dislexia and long term memory issues 1782:Thanks for your useful input JohnFromPinckney. :-) 3250:parameter for images also causes hover effect. -- 1883:Just to let you know that I've left a message at 1666:- or do screen readers tell you about colour etc? 118: 115: 109: 106: 2077:other application methodologies around the world 2063:, for example. And about this particular issue, 2004:If they update their stance, fine. But I follow 1927:can effectively be read as wikitable syntax). I 1345:But some people may not find it as "pretty". -- 3782:machines trying to extract and reuse the data. 3034: 1795:small text is way harder to read for everyone 8: 1491:Calculating the number of columns in a table 3552:make the first row header. Need an example? 3501:Colspan/Rowspan and colgroup/rowgroup scope 2131:suitably transliterated for them? Cheers. 1811:, for advanced users or Wikiproject members 2424:Well, well... The French RGAA is like the 3731:I'll post an example of my suggestion at 3696:Column headers in the middle of the table 1824:Knowledge:WikiProject Discographies/style 1804:An overview of readability best practices 1744:Knowledge:WikiProject Discographies/style 1502:between empty and row-spanned cells). -- 1009:Avoiding more than two levels of headers 4186:The Big Bang Theory (season 6)#Episodes 4182:The Big Bang Theory (season 4)#Episodes 4178:The Big Bang Theory (season 1)#Episodes 1887:. You might want to comment there. ;-) 4247:Do not edit the contents of this page. 3834:several small improvements over time. 2696:Issue with bold links in table headers 2671:Template:Infobox US university ranking 1911:Scope and simple tables, WCAG 2.0 H63. 730: 348: 112: 52:Do not edit the contents of this page. 4002:Two and a Half Men (season 9)#Ratings 3363:in the guideline about tooltips. The 736: 733: 727: 724: 626:of code for a small change. However, 354: 351: 345: 342: 7: 4174:List of The Big Bang Theory episodes 3458:Listed buildings in Poulton-le-Fylde 3361:added an exception for abbreviations 2156:" would be fitting. What do you say? 3440:Sortability/unsortability and scope 3839:add this example in our guidelines 2766:I have the feeling you don't read 32: 1746:? Thanks for the good work here. 1717:Minimum font-size recommendations 1189: 1129: 1078:Sorted by country alphabetically 4232: 3842:for your understanding. Cheers, 1691:Layout for wikitable row headers 1489:It's actually a UAAG issue. See 1199: 1154: 1144: 1139: 1094: 1044: 37: 3387: 3374: 1867:Knowledge:WikiProject Usability 1727:style="width:2em;font-size:75%" 1194: 1149: 1134: 1089: 2286:As for the need of an expert: 1897:01:03, 29 September 2010 (UTC) 1879:07:37, 28 September 2010 (UTC) 1861:05:53, 28 September 2010 (UTC) 1839:20:15, 21 September 2010 (UTC) 1778:19:20, 21 September 2010 (UTC) 1759:11:18, 21 September 2010 (UTC) 1712:22:04, 15 September 2010 (UTC) 1648:00:59, 26 September 2010 (UTC) 1631:04:45, 21 September 2010 (UTC) 1602:01:35, 21 September 2010 (UTC) 1571:22:31, 15 September 2010 (UTC) 1556:22:42, 13 September 2010 (UTC) 1526:22:05, 15 September 2010 (UTC) 1512:21:58, 13 September 2010 (UTC) 1484:20:18, 13 September 2010 (UTC) 1466:Open question on missing cells 1456:16:01, 12 September 2010 (UTC) 1416:04:06, 12 September 2010 (UTC) 1380:01:20, 12 September 2010 (UTC) 1355:16:27, 11 September 2010 (UTC) 1184: 1124: 1062:17:31, 12 September 2010 (UTC) 1039:15:16, 10 September 2010 (UTC) 1024:15:05, 10 September 2010 (UTC) 1003:01:44, 21 September 2010 (UTC) 984:19:37, 12 September 2010 (UTC) 696:17:29, 12 September 2010 (UTC) 665:04:35, 11 September 2010 (UTC) 604:14:47, 10 September 2010 (UTC) 18:Knowledge talk:Manual of Style 1: 3472:13:17, 19 February 2011 (UTC) 3211:08:09, 19 November 2010 (UTC) 3197:01:15, 19 November 2010 (UTC) 3163:08:34, 18 November 2010 (UTC) 3127:14:33, 21 November 2010 (UTC) 3113:01:19, 19 November 2010 (UTC) 3099:21:32, 17 November 2010 (UTC) 3084:01:07, 17 November 2010 (UTC) 3066:00:38, 17 November 2010 (UTC) 3051:00:30, 17 November 2010 (UTC) 3025:00:25, 17 November 2010 (UTC) 3007:00:04, 17 November 2010 (UTC) 2971:00:01, 17 November 2010 (UTC) 2956:23:57, 16 November 2010 (UTC) 2938:23:55, 16 November 2010 (UTC) 2922:23:51, 16 November 2010 (UTC) 2902:21:23, 17 November 2010 (UTC) 2882:23:46, 16 November 2010 (UTC) 2846:23:41, 16 November 2010 (UTC) 2828:23:39, 16 November 2010 (UTC) 2813:23:33, 16 November 2010 (UTC) 2798:23:29, 16 November 2010 (UTC) 2780:23:21, 16 November 2010 (UTC) 2762:23:19, 16 November 2010 (UTC) 2743:23:12, 16 November 2010 (UTC) 2725:23:10, 16 November 2010 (UTC) 2710:23:00, 16 November 2010 (UTC) 2684:23:10, 16 November 2010 (UTC) 2665:22:37, 16 November 2010 (UTC) 2628:07:34, 16 November 2010 (UTC) 2568:21:15, 17 November 2010 (UTC) 2549:00:10, 17 November 2010 (UTC) 2535:23:51, 16 November 2010 (UTC) 2521:23:14, 16 November 2010 (UTC) 2506:22:37, 16 November 2010 (UTC) 2488:08:05, 16 November 2010 (UTC) 2468:07:34, 16 November 2010 (UTC) 2443:22:37, 16 November 2010 (UTC) 2420:07:24, 16 November 2010 (UTC) 2406:06:20, 16 November 2010 (UTC) 2391:23:03, 15 November 2010 (UTC) 2376:22:55, 15 November 2010 (UTC) 1919:but I got told to come here. 1695:This is a reminder about the 1395:a:visited { color: #8800C0; } 1164: 1159: 1104: 1099: 714:style="padding: 0.2em 0.8em;" 4212:00:49, 24 October 2012 (UTC) 4163:22:46, 23 October 2012 (UTC) 4144:21:35, 23 October 2012 (UTC) 4129:19:46, 23 October 2012 (UTC) 4106:01:37, 24 October 2012 (UTC) 4089:18:28, 23 October 2012 (UTC) 4074:15:09, 23 October 2012 (UTC) 4045:13:54, 23 October 2012 (UTC) 4023:03:15, 23 October 2012 (UTC) 3400:21:31, 15 January 2011 (UTC) 2892:lame comments from here on. 2651:header, no less and no more. 2356:19:42, 8 November 2010 (UTC) 2329:19:34, 8 November 2010 (UTC) 2315:19:29, 8 November 2010 (UTC) 2301:19:12, 8 November 2010 (UTC) 2257:08:22, 8 November 2010 (UTC) 2243:22:03, 7 November 2010 (UTC) 2215:21:20, 7 November 2010 (UTC) 2201:18:20, 7 November 2010 (UTC) 2179:18:02, 7 November 2010 (UTC) 2141:17:44, 7 November 2010 (UTC) 2089:17:59, 7 November 2010 (UTC) 2061:WebAIM section 508 checklist 2051:16:38, 21 October 2010 (UTC) 2026:15:25, 21 October 2010 (UTC) 2000:10:11, 21 October 2010 (UTC) 1979:00:57, 21 October 2010 (UTC) 1953:23:47, 20 October 2010 (UTC) 1179: 1174: 1119: 1114: 887:Released: September 24, 1991 505:Released: September 24, 1991 309: 306: 303: 300: 297: 294: 291: 288: 285: 282: 266:Released: September 24, 1991 241: 238: 235: 232: 229: 226: 223: 220: 217: 214: 3891:out there. As a student in 3543:06:34, 26 August 2011 (UTC) 3419:20:33, 2 January 2011 (UTC) 3344:16:01, 3 January 2011 (UTC) 3328:16:00, 3 January 2011 (UTC) 3313:14:38, 3 January 2011 (UTC) 3295:14:25, 3 January 2011 (UTC) 3278:10:37, 3 January 2011 (UTC) 3260:10:29, 3 January 2011 (UTC) 3237:19:14, 2 January 2011 (UTC) 2834:Yeah Yeah Yeahs discography 2230:you asked about the expert? 1169: 1109: 4288: 3446:class="wikitable sortable" 3299:Sorry, I should have said 2265:Anyway, I'll soon have an 1815:List of further references 686:becomes useless. Regards, 3829:Compromise about rowspans 3035:#Avoiding rowspan/colspan 2596:or what are currently in 2010:World Wide Web Consortium 1939:to back up these claims. 1826:and try to convince them. 1274: 1205: 1198: 1193: 1188: 1183: 1178: 1173: 1168: 1163: 1158: 1153: 1148: 1143: 1138: 1133: 1128: 1123: 1118: 1113: 1108: 1103: 1098: 1093: 1088: 1085: 1082: 876: 795: 788: 783: 778: 773: 768: 763: 758: 753: 748: 743: 645:(with another layout) in 620:style="text-align:center" 494: 413: 406: 401: 396: 391: 386: 381: 376: 371: 366: 361: 256: 177: 170: 165: 160: 155: 150: 145: 140: 135: 130: 125: 3962:21:42, 7 June 2012 (UTC) 3936:10:53, 7 June 2012 (UTC) 3908:04:54, 7 June 2012 (UTC) 3875:23:19, 6 June 2012 (UTC) 3852:20:30, 6 June 2012 (UTC) 3817:21:22, 3 June 2012 (UTC) 3799:21:13, 3 June 2012 (UTC) 3767:17:41, 3 June 2012 (UTC) 3745:00:30, 2 June 2012 (UTC) 3722:00:41, 1 June 2012 (UTC) 3684:09:29, 2 June 2012 (UTC) 3663:06:08, 2 June 2012 (UTC) 3648:03:34, 2 June 2012 (UTC) 3634:03:04, 2 June 2012 (UTC) 3584:22:43, 6 June 2015 (UTC) 3566:21:19, 6 June 2012 (UTC) 3495:23:04, 2 June 2012 (UTC) 3434:02:58, 2 June 2012 (UTC) 1685:15:22, 11 May 2020 (UTC) 1534:Avoiding rowspan/colspan 3613:21:51, 9 May 2012 (UTC) 2396:mean something to you? 1809:Research on readability 1444:Seven plus or minus two 806:Released: June 15, 1989 628:The Prodigy discography 424:Released: June 15, 1989 187:Released: June 15, 1989 3033:of March. And see the 2615:or overly optimistic. 2267:accessibility training 2067:explicitely says that 2030:We're following W3C's 1723:the discogs style page 1516:OK, thanks RexxS. :-) 1423:!important declaration 944:26 million (worldwide) 562:26 million (worldwide) 318:26 million (worldwide) 4245:of past discussions. 3889:multiple disabilities 2729:No, MOS is MOS. FLC 2275:You can also contact 2071:. The ITAA guideline 2008:so would believe the 731:Peak chart positions 349:Peak chart positions 113:Peak chart positions 50:of past discussions. 3893:occupational therapy 1366:should never change. 26:Data tables tutorial 4170:The Big Bang Theory 3837:However, we cannot 3595:and plainrowheaders 2598:Rihanna discography 1985:WCAG 2.0 TECHS, H63 1079: 972:not align=center !! 721: 339: 103: 4054:been around since 3483:class="unsortable" 3454:class="unsortable" 3151:Essjay controversy 1933:Essjay controversy 1077: 899:Format: CD, CS, LP 719: 675:doesn't work with 517:Format: CD, CS, LP 337: 278:Format: CD, CS, LP 101: 4275: 4274: 4257: 4256: 4251:current talk page 3996:== References == 3986:== References == 3452:clashed with the 3405:"plainrowheaders" 3048: 2992: 2023: 1950: 1844:find them; is it 1343: 1342: 968: 967: 896: 815: 677:class="wikitable" 586: 585: 514: 433: 332: 331: 275: 196: 80: 79: 62: 61: 56:current talk page 4279: 4266: 4259: 4258: 4236: 4235: 4229: 4210: 4197: 4191: 4103: 4071: 4021: 3932: 3927: 3871: 3866: 3755:A Thousand Doors 3710:A Thousand Doors 3572:irregular tables 3540: 3534: 3528: 3524: 3520: 3516: 3512: 3508: 3484: 3480: 3469: 3464: 3455: 3451: 3447: 3411:The Rambling Man 3389: 3376: 3372: 3366: 3341: 3320:The Rambling Man 3292: 3270:The Rambling Man 3245: 3229:The Rambling Man 3203:The Rambling Man 3155:The Rambling Man 3044: 2999:The Rambling Man 2988: 2948:The Rambling Man 2914:The Rambling Man 2874:The Rambling Man 2820:The Rambling Man 2805:The Rambling Man 2772:The Rambling Man 2735:The Rambling Man 2702:The Rambling Man 2619:JohnFromPinckney 2541:The Rambling Man 2513:The Rambling Man 2480:The Rambling Man 2459:JohnFromPinckney 2412:The Rambling Man 2383:The Rambling Man 2348:The Rambling Man 2307:The Rambling Man 2249:The Rambling Man 2207:The Rambling Man 2193:The Rambling Man 2167: 2161: 2155: 2149: 2133:The Rambling Man 2130: 2124: 2120: 2114: 2019: 2006:reliable sources 1946: 1852:JohnFromPinckney 1750:JohnFromPinckney 1733: 1728: 1396: 1201: 1196: 1191: 1186: 1181: 1176: 1171: 1166: 1161: 1156: 1151: 1146: 1141: 1136: 1131: 1126: 1121: 1116: 1111: 1106: 1101: 1096: 1091: 1080: 1070:Images and color 1052: 1048: 1047: 961: 960:2× Platinum (UK) 956: 945: 940: 894: 872: 867: 866:1.7 million (US) 813: 722: 715: 685: 678: 674: 654: 648: 644: 638: 621: 614: 579: 578:2× Platinum (UK) 574: 563: 558: 512: 490: 485: 484:1.7 million (US) 431: 340: 328: 327:2× Platinum (UK) 324: 319: 315: 273: 252: 247: 246:1.7 million (US) 194: 104: 96: 90: 83:Unbulleted lists 71: 64: 63: 41: 40: 34: 4287: 4286: 4282: 4281: 4280: 4278: 4277: 4276: 4262: 4233: 4207: 4199: 4195: 4189: 4101: 4069: 4018: 4010: 3997: 3987: 3976: 3930: 3925: 3885: 3869: 3864: 3831: 3698: 3597: 3538: 3532: 3526: 3522: 3518: 3514: 3510: 3506: 3503: 3482: 3478: 3467: 3462: 3453: 3449: 3445: 3442: 3407: 3370: 3364: 3339: 3290: 3249: 3243: 3221: 3147: 3040:Rambo's Revenge 2984:Rambo's Revenge 2910: 2698: 2165: 2159: 2153: 2147: 2128: 2122: 2118: 2112: 2105: 2015:Rambo's Revenge 1942:Rambo's Revenge 1937:reliable source 1913: 1732:</small: --> 1730: 1726: 1719: 1693: 1536: 1468: 1394: 1361:complete their 1072: 1045: 1043: 1011: 964: 959: 954: 948: 943: 939:10 million (US) 938: 902: 870: 865: 832: 720:List of albums 713: 710: 683: 676: 673:cellpadding="5" 672: 652: 646: 642: 636: 619: 612: 582: 577: 572: 566: 561: 557:10 million (US) 556: 520: 488: 483: 450: 338:List of albums 326: 322: 317: 313: 250: 245: 102:List of albums 94: 92:Unbulleted list 88: 85: 67: 38: 30: 29: 28: 12: 11: 5: 4285: 4283: 4273: 4272: 4267: 4255: 4254: 4237: 4227: 4226: 4225: 4224: 4223: 4222: 4221: 4220: 4219: 4218: 4217: 4216: 4215: 4214: 4205: 4150: 4116: 4108: 4048: 4047: 4033: 4029: 4016: 3991: 3981: 3975: 3974:Table captions 3972: 3971: 3970: 3969: 3968: 3967: 3966: 3965: 3964: 3950: 3946: 3942: 3914: 3900:213.55.184.161 3896: 3883: 3880: 3859: 3830: 3827: 3826: 3825: 3824: 3823: 3822: 3821: 3820: 3819: 3783: 3779: 3772: 3729: 3697: 3694: 3693: 3692: 3691: 3690: 3689: 3688: 3687: 3686: 3671: 3668: 3622: 3619: 3596: 3590: 3589: 3588: 3587: 3586: 3576:Thisisnotatest 3553: 3549: 3502: 3499: 3498: 3497: 3441: 3438: 3437: 3436: 3406: 3403: 3357: 3356: 3355: 3354: 3353: 3352: 3351: 3350: 3349: 3348: 3347: 3346: 3247: 3220: 3217: 3216: 3215: 3214: 3213: 3181: 3173: 3146: 3143: 3142: 3141: 3140: 3139: 3138: 3137: 3136: 3135: 3134: 3133: 3132: 3131: 3130: 3129: 3074:. Thanks. :-) 3068: 3012: 2978: 2977: 2976: 2975: 2974: 2973: 2909: 2906: 2905: 2904: 2889: 2861: 2860: 2859: 2858: 2857: 2856: 2855: 2854: 2853: 2852: 2851: 2850: 2849: 2848: 2815: 2786:WP:DISCOGSTYLE 2697: 2694: 2693: 2692: 2691: 2690: 2689: 2688: 2687: 2686: 2652: 2648: 2647: 2646: 2643: 2637: 2634: 2612: 2601: 2594:WP:DISCOGSTYLE 2587: 2586: 2585: 2584: 2583: 2582: 2581: 2580: 2579: 2578: 2577: 2576: 2575: 2574: 2573: 2572: 2571: 2570: 2449: 2448: 2447: 2446: 2445: 2430: 2363: 2344: 2343: 2342: 2341: 2340: 2339: 2338: 2337: 2336: 2335: 2334: 2333: 2332: 2331: 2284: 2273: 2270: 2263: 2231: 2224: 2220: 2203: 2185: 2157: 2104: 2103:"Good" example 2101: 2100: 2099: 2098: 2097: 2096: 2095: 2094: 2093: 2092: 2091: 2038: 2035: 1988: 1967: 1963: 1960: 1917:discussed here 1912: 1909: 1908: 1907: 1906: 1905: 1904: 1903: 1902: 1901: 1900: 1899: 1865:Yup, that it. 1827: 1819: 1818: 1817: 1812: 1806: 1798: 1791: 1787: 1783: 1738:even smaller. 1731:<small: --> 1718: 1715: 1692: 1689: 1688: 1687: 1674: 1670: 1667: 1664: 1661: 1657: 1656: 1655: 1654: 1653: 1652: 1651: 1650: 1636: 1618: 1615: 1611: 1607: 1586: 1583: 1579: 1576: 1535: 1532: 1531: 1530: 1529: 1528: 1499: 1498: 1497: 1472:Dwain Chambers 1467: 1464: 1463: 1462: 1461: 1460: 1459: 1458: 1436: 1432: 1429: 1426: 1403: 1399: 1398: 1397: 1385: 1367: 1341: 1340: 1338: 1336: 1334: 1332: 1330: 1328: 1326: 1324: 1322: 1319: 1316: 1313: 1310: 1307: 1304: 1301: 1298: 1295: 1292: 1289: 1286: 1284: 1282: 1280: 1278: 1272: 1271: 1269: 1267: 1265: 1263: 1261: 1259: 1256: 1253: 1250: 1247: 1244: 1241: 1238: 1235: 1232: 1229: 1226: 1223: 1221: 1219: 1217: 1215: 1213: 1211: 1209: 1203: 1202: 1197: 1192: 1187: 1182: 1177: 1172: 1167: 1162: 1157: 1152: 1147: 1142: 1137: 1132: 1127: 1122: 1117: 1112: 1107: 1102: 1097: 1092: 1087: 1084: 1071: 1068: 1067: 1066: 1065: 1064: 1010: 1007: 1006: 1005: 990: 966: 965: 963: 962: 957: 951: 949: 947: 946: 941: 935: 933: 930: 927: 924: 921: 918: 915: 912: 909: 906: 903: 901: 900: 897: 888: 884: 882: 874: 873: 868: 863: 860: 857: 854: 851: 848: 845: 842: 839: 836: 833: 831: 830: 816: 807: 803: 801: 793: 792: 787: 782: 777: 772: 767: 762: 757: 752: 747: 741: 740: 738:Certifications 735: 732: 729: 728:Album details 726: 708: 703: 702: 701: 700: 699: 698: 680: 633: 632: 631: 623: 618:I agree about 616: 584: 583: 581: 580: 575: 569: 567: 565: 564: 559: 553: 551: 548: 545: 542: 539: 536: 533: 530: 527: 524: 521: 519: 518: 515: 506: 502: 500: 492: 491: 486: 481: 478: 475: 472: 469: 466: 463: 460: 457: 454: 451: 449: 448: 434: 425: 421: 419: 411: 410: 405: 400: 395: 390: 385: 380: 375: 370: 365: 359: 358: 356:Certifications 353: 350: 347: 346:Album details 344: 334:would become: 330: 329: 325: 320: 316: 314:10 million(US) 311: 308: 305: 302: 299: 296: 293: 290: 287: 284: 281: 280: 279: 276: 267: 262: 254: 253: 248: 243: 240: 237: 234: 231: 228: 225: 222: 219: 216: 213: 212: 211: 197: 188: 183: 175: 174: 169: 164: 159: 154: 149: 144: 139: 134: 129: 123: 122: 120:Certifications 117: 114: 111: 110:Album details 108: 84: 81: 78: 77: 72: 60: 59: 42: 31: 15: 14: 13: 10: 9: 6: 4: 3: 2: 4284: 4271: 4268: 4265: 4261: 4260: 4252: 4248: 4244: 4243: 4238: 4231: 4230: 4213: 4208: 4202: 4194: 4187: 4183: 4179: 4175: 4171: 4166: 4165: 4164: 4160: 4156: 4151: 4147: 4146: 4145: 4141: 4137: 4132: 4131: 4130: 4126: 4122: 4117: 4113: 4109: 4107: 4104: 4099: 4098: 4092: 4091: 4090: 4086: 4082: 4077: 4076: 4075: 4072: 4067: 4066: 4061: 4057: 4052: 4051: 4050: 4049: 4046: 4042: 4038: 4034: 4030: 4027: 4026: 4025: 4024: 4019: 4013: 4007: 4003: 3990: 3980: 3973: 3963: 3959: 3955: 3951: 3947: 3943: 3939: 3938: 3937: 3934: 3933: 3928: 3920: 3915: 3911: 3910: 3909: 3905: 3901: 3897: 3894: 3890: 3881: 3878: 3877: 3876: 3873: 3872: 3867: 3860: 3856: 3855: 3854: 3853: 3849: 3845: 3840: 3835: 3828: 3818: 3814: 3810: 3806: 3802: 3801: 3800: 3796: 3792: 3788: 3784: 3780: 3777: 3773: 3770: 3769: 3768: 3764: 3760: 3756: 3752: 3748: 3747: 3746: 3742: 3738: 3734: 3730: 3726: 3725: 3724: 3723: 3719: 3715: 3711: 3707: 3703: 3695: 3685: 3681: 3677: 3672: 3669: 3666: 3665: 3664: 3660: 3656: 3651: 3650: 3649: 3645: 3641: 3637: 3636: 3635: 3631: 3627: 3623: 3620: 3617: 3616: 3615: 3614: 3610: 3606: 3602: 3594: 3591: 3585: 3581: 3577: 3573: 3569: 3568: 3567: 3563: 3559: 3554: 3550: 3547: 3546: 3545: 3544: 3541: 3536: 3535: 3521:", but also " 3500: 3496: 3492: 3488: 3479:! scope="col" 3476: 3475: 3474: 3473: 3470: 3465: 3459: 3450:! scope="col" 3439: 3435: 3431: 3427: 3423: 3422: 3421: 3420: 3416: 3412: 3404: 3402: 3401: 3397: 3393: 3383: 3379: 3369: 3362: 3345: 3342: 3337: 3336: 3331: 3330: 3329: 3325: 3321: 3316: 3315: 3314: 3310: 3306: 3302: 3298: 3297: 3296: 3293: 3288: 3287: 3281: 3280: 3279: 3275: 3271: 3267: 3263: 3262: 3261: 3257: 3253: 3244:<abbr: --> 3241: 3240: 3239: 3238: 3234: 3230: 3226: 3218: 3212: 3208: 3204: 3201:Never mind. 3200: 3199: 3198: 3194: 3190: 3186: 3182: 3179: 3174: 3171: 3167: 3166: 3165: 3164: 3160: 3156: 3152: 3144: 3128: 3124: 3120: 3116: 3115: 3114: 3110: 3106: 3102: 3101: 3100: 3096: 3092: 3087: 3086: 3085: 3081: 3077: 3073: 3069: 3067: 3063: 3059: 3054: 3053: 3052: 3049: 3047: 3042: 3041: 3036: 3032: 3028: 3027: 3026: 3022: 3018: 3013: 3010: 3009: 3008: 3004: 3000: 2996: 2995: 2994: 2993: 2991: 2986: 2985: 2972: 2968: 2964: 2959: 2958: 2957: 2953: 2949: 2945: 2941: 2940: 2939: 2935: 2931: 2926: 2925: 2924: 2923: 2919: 2915: 2907: 2903: 2899: 2895: 2890: 2886: 2885: 2884: 2883: 2879: 2875: 2871: 2867: 2847: 2843: 2839: 2835: 2831: 2830: 2829: 2825: 2821: 2816: 2814: 2810: 2806: 2801: 2800: 2799: 2795: 2791: 2787: 2783: 2782: 2781: 2777: 2773: 2769: 2765: 2764: 2763: 2759: 2755: 2750: 2746: 2745: 2744: 2740: 2736: 2732: 2728: 2727: 2726: 2722: 2718: 2714: 2713: 2712: 2711: 2707: 2703: 2695: 2685: 2681: 2677: 2672: 2669:For example, 2668: 2667: 2666: 2662: 2658: 2653: 2649: 2644: 2641: 2640: 2638: 2635: 2631: 2630: 2629: 2626: 2624: 2620: 2613: 2610: 2606: 2602: 2599: 2595: 2591: 2590: 2589: 2588: 2569: 2565: 2561: 2556: 2552: 2551: 2550: 2546: 2542: 2538: 2537: 2536: 2532: 2528: 2524: 2523: 2522: 2518: 2514: 2509: 2508: 2507: 2503: 2499: 2495: 2491: 2490: 2489: 2485: 2481: 2476: 2471: 2470: 2469: 2466: 2464: 2460: 2454: 2450: 2444: 2440: 2436: 2431: 2427: 2423: 2422: 2421: 2417: 2413: 2409: 2408: 2407: 2403: 2399: 2394: 2393: 2392: 2388: 2384: 2379: 2378: 2377: 2373: 2369: 2364: 2360: 2359: 2358: 2357: 2353: 2349: 2330: 2326: 2322: 2318: 2317: 2316: 2312: 2308: 2304: 2303: 2302: 2298: 2294: 2289: 2285: 2282: 2278: 2274: 2271: 2268: 2264: 2260: 2259: 2258: 2254: 2250: 2246: 2245: 2244: 2240: 2236: 2232: 2229: 2228:clarification 2225: 2221: 2218: 2217: 2216: 2212: 2208: 2204: 2202: 2198: 2194: 2190: 2186: 2182: 2181: 2180: 2176: 2172: 2164: 2158: 2152: 2145: 2144: 2143: 2142: 2138: 2134: 2127: 2117: 2110: 2102: 2090: 2086: 2082: 2078: 2074: 2073:says the same 2070: 2066: 2062: 2058: 2054: 2053: 2052: 2048: 2044: 2039: 2036: 2033: 2029: 2028: 2027: 2024: 2022: 2017: 2016: 2011: 2007: 2003: 2002: 2001: 1997: 1993: 1989: 1986: 1982: 1981: 1980: 1976: 1972: 1968: 1964: 1961: 1957: 1956: 1955: 1954: 1951: 1949: 1944: 1943: 1938: 1934: 1930: 1926: 1922: 1918: 1910: 1898: 1894: 1890: 1886: 1882: 1881: 1880: 1876: 1872: 1868: 1864: 1863: 1862: 1859: 1857: 1853: 1847: 1842: 1841: 1840: 1836: 1832: 1828: 1825: 1820: 1816: 1813: 1810: 1807: 1805: 1802: 1801: 1799: 1796: 1792: 1788: 1784: 1781: 1780: 1779: 1775: 1771: 1767: 1763: 1762: 1761: 1760: 1757: 1755: 1751: 1745: 1739: 1735: 1724: 1716: 1714: 1713: 1709: 1705: 1700: 1698: 1690: 1686: 1682: 1678: 1675: 1671: 1668: 1665: 1662: 1659: 1658: 1649: 1645: 1641: 1637: 1634: 1633: 1632: 1628: 1624: 1619: 1616: 1612: 1608: 1605: 1604: 1603: 1599: 1595: 1591: 1587: 1584: 1580: 1577: 1574: 1573: 1572: 1568: 1564: 1560: 1559: 1558: 1557: 1553: 1549: 1545: 1541: 1533: 1527: 1523: 1519: 1515: 1514: 1513: 1509: 1505: 1500: 1495: 1494: 1492: 1488: 1487: 1486: 1485: 1481: 1477: 1473: 1465: 1457: 1453: 1449: 1445: 1441: 1437: 1433: 1430: 1427: 1424: 1419: 1418: 1417: 1413: 1409: 1404: 1400: 1393: 1392: 1390: 1386: 1383: 1382: 1381: 1377: 1373: 1368: 1364: 1359: 1358: 1357: 1356: 1352: 1348: 1339: 1337: 1335: 1333: 1331: 1329: 1327: 1325: 1323: 1320: 1317: 1314: 1311: 1308: 1305: 1302: 1299: 1296: 1293: 1290: 1287: 1285: 1283: 1281: 1279: 1277: 1273: 1270: 1268: 1266: 1264: 1262: 1260: 1257: 1254: 1251: 1248: 1245: 1242: 1239: 1236: 1233: 1230: 1227: 1224: 1222: 1220: 1218: 1216: 1214: 1212: 1210: 1208: 1204: 1081: 1075: 1069: 1063: 1059: 1055: 1051: 1042: 1041: 1040: 1036: 1032: 1028: 1027: 1026: 1025: 1021: 1017: 1008: 1004: 1000: 996: 991: 988: 987: 986: 985: 981: 977: 973: 958: 953: 952: 950: 942: 937: 936: 934: 931: 928: 925: 922: 919: 916: 913: 910: 907: 904: 898: 893: 889: 886: 885: 883: 881: 880: 875: 871:Platinum (US) 869: 864: 861: 858: 855: 852: 849: 846: 843: 840: 837: 834: 829: 825: 821: 817: 812: 808: 805: 804: 802: 800: 799: 794: 791: 786: 781: 776: 771: 766: 761: 756: 751: 746: 742: 739: 723: 717: 707: 697: 693: 689: 681: 670: 669: 668: 667: 666: 662: 658: 651: 641: 634: 629: 624: 617: 610: 609: 608: 607: 606: 605: 601: 597: 591: 576: 571: 570: 568: 560: 555: 554: 552: 549: 546: 543: 540: 537: 534: 531: 528: 525: 522: 516: 511: 507: 504: 503: 501: 499: 498: 493: 489:Platinum (US) 487: 482: 479: 476: 473: 470: 467: 464: 461: 458: 455: 452: 447: 443: 439: 435: 430: 426: 423: 422: 420: 418: 417: 412: 409: 404: 399: 394: 389: 384: 379: 374: 369: 364: 360: 357: 341: 335: 321: 312: 277: 272: 268: 265: 264: 263: 261: 260: 255: 251:Platinum (US) 249: 244: 210: 206: 202: 198: 193: 189: 186: 185: 184: 182: 181: 176: 173: 168: 163: 158: 153: 148: 143: 138: 133: 128: 124: 121: 105: 99: 93: 82: 76: 73: 70: 66: 65: 57: 53: 49: 48: 43: 36: 35: 27: 23: 22:Accessibility 19: 4263: 4246: 4240: 4201:AussieLegend 4111: 4095: 4063: 4012:AussieLegend 3998: 3988: 3977: 3923: 3918: 3862: 3836: 3832: 3702:good example 3699: 3598: 3531: 3504: 3443: 3408: 3384: 3380: 3358: 3333: 3300: 3284: 3265: 3222: 3148: 3045: 3039: 3030: 2989: 2983: 2979: 2943: 2911: 2869: 2862: 2767: 2748: 2730: 2699: 2616: 2608: 2604: 2474: 2456: 2452: 2345: 2226:What is the 2188: 2109:this section 2106: 2020: 2014: 1947: 1941: 1924: 1914: 1849: 1747: 1740: 1736: 1720: 1701: 1694: 1539: 1537: 1469: 1388: 1344: 1073: 1049: 1012: 971: 969: 955:Diamond (US) 895:(DGC #24425) 877: 796: 711: 704: 684:align=center 589: 587: 573:Diamond (US) 513:(DGC #24425) 495: 414: 333: 323:Diamond (US) 274:(DGC #24425) 257: 178: 86: 68: 51: 45: 4239:This is an 2603:You wrote, 2455:pointless. 2426:section 508 2057:Section 508 1959:afterwards. 1925:TH elements 1363:Style Guide 44:This is an 4149:guideline. 3533:Afaber012 3509:" and/or " 1582:apologies. 1440:breadcrumb 1014:tables. -- 4270:Archive 2 4264:Archive 1 4180:and even 4136:Elizium23 3735:. Yours, 3655:Elizium23 3605:Elizium23 3390:Regards, 3225:WP:ACCESS 3153:, do we? 1402:elements. 1207:Australia 879:Nevermind 497:Nevermind 259:Nevermind 75:Archive 2 69:Archive 1 4155:Dodoïste 4081:Dodoïste 4056:JAWS 6.0 4037:Dodoïste 3954:Dodoïste 3941:correct. 3926:Spinning 3865:Spinning 3844:Dodoïste 3809:Dodoïste 3791:Dodoïste 3763:contribs 3737:Dodoïste 3718:contribs 3676:Dodoïste 3640:Dodoïste 3626:Dodoïste 3558:Dodoïste 3527:rowgroup 3523:colgroup 3487:Dodoïste 3426:Dodoïste 3392:Dodoïste 3318:found). 3301:may read 3219:Tooltips 3189:Dodoïste 3170:user:Lgd 3119:Dodoïste 3105:Dodoïste 3091:Dodoïste 3076:Dodoïste 3058:Dodoïste 3017:Dodoïste 2963:Dodoïste 2930:Dodoïste 2908:Disputed 2894:Dodoïste 2838:Dodoïste 2790:Dodoïste 2754:Dodoïste 2717:Dodoïste 2676:Dodoïste 2657:Dodoïste 2560:Dodoïste 2555:user:Lgd 2527:Dodoïste 2498:Dodoïste 2435:Dodoïste 2398:Dodoïste 2368:Dodoïste 2321:Dodoïste 2293:Dodoïste 2235:Dodoïste 2171:Dodoïste 2081:Dodoïste 2043:Dodoïste 1992:Dodoïste 1971:Dodoïste 1929:got told 1921:W3C says 1889:Dodoïste 1871:Dodoïste 1831:Dodoïste 1704:Dodoïste 1640:Dodoïste 1594:Dodoïste 1563:Dodoïste 1518:Dodoïste 1476:Dodoïste 1448:Dodoïste 1372:Dodoïste 1086:Purpose 1083:Country 1054:Dodoïste 1031:Dodoïste 995:Dodoïste 824:cassette 818:Format: 814:(SP #34) 688:Dodoïste 657:Dodoïste 640:Flatlist 622:as well. 442:cassette 436:Format: 432:(SP #34) 205:cassette 199:Format: 195:(SP #34) 24:‎ | 20:‎ | 4242:archive 3949:issues. 3787:MOS:DTT 3751:MOS:DTT 3539:(talk) 3525:" and " 3517:" and " 3511:rowspan 3507:colspan 3463:Beloved 3145:Specify 2866:problem 1677:Irtapil 890:Label: 811:Sub Pop 809:Label: 508:Label: 429:Sub Pop 427:Label: 269:Label: 192:Sub Pop 190:Label: 47:archive 4097:Graham 4065:Graham 3913:point? 3728:table. 3601:WP:DTT 3593:WP:AWB 3335:Graham 3305:Anneyh 3286:Graham 3252:Anneyh 3185:WebAIM 3046:(talk) 2990:(talk) 2494:WP:ALT 2475:That's 2281:WP:ALT 2277:WebAIM 2075:. And 2065:WebAIM 2021:(talk) 1948:(talk) 1786:issue. 1276:Canada 798:Bleach 734:Sales 725:Title 650:Navbox 416:Bleach 352:Sales 343:Title 180:Bleach 116:Sales 107:Title 4121:RexxS 3931:Spark 3919:would 3870:Spark 3468:Freak 2609:brief 1770:RexxS 1623:RexxS 1548:RexxS 1504:RexxS 1408:RexxS 1389:/.css 1347:RexxS 1016:RexxS 976:RexxS 970:The ( 596:RexxS 16:< 4193:main 4159:talk 4140:talk 4125:talk 4085:talk 4060:NVDA 4041:talk 4006:This 3958:talk 3904:talk 3848:talk 3813:talk 3795:talk 3776:JAWS 3759:talk 3741:talk 3714:talk 3680:talk 3659:talk 3644:talk 3630:talk 3609:talk 3580:talk 3562:talk 3491:talk 3481:and 3460:. -- 3430:talk 3415:talk 3396:talk 3388:Jan. 3368:abbr 3324:talk 3309:talk 3274:talk 3256:talk 3233:talk 3207:talk 3193:talk 3159:talk 3123:talk 3109:talk 3095:talk 3080:talk 3062:talk 3021:talk 3003:talk 2967:talk 2952:talk 2934:talk 2918:talk 2898:talk 2878:talk 2842:talk 2824:talk 2809:talk 2794:talk 2776:talk 2758:talk 2749:very 2739:talk 2721:talk 2706:talk 2680:talk 2661:talk 2623:talk 2564:talk 2545:talk 2531:talk 2517:talk 2502:talk 2484:talk 2463:talk 2439:talk 2416:talk 2402:talk 2387:talk 2372:talk 2352:talk 2325:talk 2311:talk 2297:talk 2288:WCAG 2253:talk 2239:talk 2211:talk 2197:talk 2175:talk 2137:talk 2085:talk 2059:has 2047:talk 2032:WCAG 1996:talk 1975:talk 1893:talk 1875:talk 1856:talk 1846:here 1835:talk 1774:talk 1754:talk 1708:talk 1681:talk 1644:talk 1627:talk 1598:talk 1567:talk 1552:talk 1522:talk 1508:talk 1480:talk 1452:talk 1412:talk 1376:talk 1351:talk 1058:talk 1050:Done 1035:talk 1020:talk 999:talk 980:talk 692:talk 661:talk 600:talk 590:must 3519:row 3515:col 3266:not 3248:alt 3178:DIY 2944:all 2888:me. 2870:lot 2768:all 2731:has 2453:not 2223:is. 2189:not 2163:URS 2151:URS 2126:URS 2116:URS 2107:In 892:DGC 862:33 850:30 844:24 841:26 838:34 835:89 785:SWI 780:SWE 775:NOR 765:NLD 760:FIN 755:AUT 750:AUS 510:DGC 480:33 468:30 462:24 459:26 456:34 453:89 403:SWI 398:SWE 393:NOR 383:NLD 378:FIN 373:AUT 368:AUS 271:DGC 242:33 230:30 224:24 221:26 218:34 215:89 167:SWI 162:SWE 157:NOR 147:NLD 142:FIN 137:AUT 132:AUS 4196:}} 4190:{{ 4161:) 4142:) 4127:) 4102:87 4087:) 4070:87 4043:) 4009:-- 3960:) 3906:) 3850:) 3815:) 3797:) 3789:. 3765:) 3761:| 3753:? 3743:) 3720:) 3716:| 3682:) 3661:) 3646:) 3632:) 3611:) 3582:) 3574:. 3564:) 3493:) 3432:) 3417:) 3398:) 3375:J. 3371:}} 3365:{{ 3359:I 3340:87 3326:) 3311:) 3291:87 3276:) 3258:) 3235:) 3209:) 3195:) 3161:) 3125:) 3111:) 3097:) 3082:) 3064:) 3031:st 3029:31 3023:) 3005:) 2969:) 2954:) 2936:) 2920:) 2900:) 2880:) 2844:) 2826:) 2811:) 2796:) 2778:) 2760:) 2741:) 2723:) 2708:) 2682:) 2663:) 2617:— 2566:) 2547:) 2533:) 2519:) 2504:) 2486:) 2457:— 2441:) 2418:) 2404:) 2389:) 2374:) 2354:) 2327:) 2313:) 2299:) 2255:) 2241:) 2213:) 2199:) 2177:) 2166:}} 2160:{{ 2154:}} 2148:{{ 2139:) 2129:}} 2123:{{ 2119:}} 2113:{{ 2087:) 2049:) 1998:) 1977:) 1895:) 1877:) 1850:— 1848:? 1837:) 1776:) 1748:— 1710:) 1683:) 1646:) 1629:) 1621:-- 1600:) 1569:) 1554:) 1540:do 1524:) 1510:) 1493:: 1482:) 1454:) 1414:) 1406:-- 1378:) 1353:) 1321:x 1318:x 1315:x 1312:x 1309:x 1306:x 1303:x 1300:x 1297:x 1294:x 1291:x 1288:x 1258:x 1255:x 1252:x 1249:x 1246:x 1243:x 1240:x 1237:x 1234:x 1231:x 1228:x 1225:x 1060:) 1037:) 1022:) 1001:) 982:) 932:7 929:2 926:1 923:2 920:2 917:5 914:1 911:2 908:2 905:1 859:— 856:— 853:— 847:— 828:LP 826:, 822:, 820:CD 790:UK 770:NZ 745:US 694:) 663:) 653:}} 647:{{ 643:}} 637:{{ 613:em 602:) 550:7 547:2 544:1 541:2 538:2 535:5 532:1 529:2 526:2 523:1 477:— 474:— 471:— 465:— 446:LP 444:, 440:, 438:CD 408:UK 388:NZ 363:US 310:7 307:2 304:1 301:2 298:2 295:5 292:1 289:2 286:2 283:1 239:— 236:— 233:— 227:— 209:LP 207:, 203:, 201:CD 172:UK 152:NZ 127:US 95:}} 89:{{ 4253:. 4209:) 4206:✉ 4203:( 4157:( 4138:( 4123:( 4083:( 4039:( 4020:) 4017:✉ 4014:( 3956:( 3902:( 3846:( 3811:( 3793:( 3757:( 3739:( 3712:( 3678:( 3657:( 3642:( 3628:( 3607:( 3578:( 3560:( 3489:( 3428:( 3413:( 3394:( 3322:( 3307:( 3272:( 3254:( 3231:( 3205:( 3191:( 3180:. 3157:( 3121:( 3107:( 3093:( 3078:( 3060:( 3019:( 3001:( 2965:( 2950:( 2932:( 2916:( 2896:( 2876:( 2840:( 2822:( 2807:( 2792:( 2774:( 2756:( 2737:( 2719:( 2704:( 2678:( 2659:( 2625:) 2621:( 2562:( 2543:( 2529:( 2515:( 2500:( 2482:( 2465:) 2461:( 2437:( 2414:( 2400:( 2385:( 2370:( 2350:( 2323:( 2309:( 2295:( 2251:( 2237:( 2209:( 2195:( 2173:( 2135:( 2083:( 2045:( 1994:( 1973:( 1891:( 1873:( 1858:) 1854:( 1833:( 1772:( 1756:) 1752:( 1706:( 1679:( 1642:( 1625:( 1596:( 1565:( 1550:( 1520:( 1506:( 1478:( 1450:( 1410:( 1374:( 1349:( 1200:N 1195:O 1190:S 1185:A 1180:J 1175:J 1170:M 1165:A 1160:M 1155:F 1150:J 1145:D 1140:N 1135:O 1130:S 1125:A 1120:J 1115:J 1110:M 1105:A 1100:M 1095:F 1090:J 1056:( 1033:( 1018:( 997:( 978:( 690:( 659:( 598:( 58:.

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge

talk:Manual of Style/Accessibility/Data tables tutorial/Archive 1 - Knowledge

Index