Knowledge talk:Manual of Style/Accessibility/Archive 11

5943:

Then that essay should be made widely available. Following this the actually MOS should be updated as suggested above. HOWEVER changes should not be imposed on others until it is clear what the actual goal is. Dodieste can be my testiment that the recent on-goings at Wikiproject: Discographies has been a mad mess of confusion. Those trying to implement the accessibility changes point to a number of different pages all with conflicting advice. It would be better if everything was centralized and if simple non-jargon terms were used. Only one the accessibility policy is agreed can people and projects adapt. But there needs to be a clear outline which I feel at the moment there isn't. I'm sorry if this sounds negative but I do support a movement towards making wikipedia easier to access for all involved but like Dodieste has said... it needs to be done without drama and without overwhelming people. ----

8211:: "A table rendering process where the contents of the cells become a series of paragraphs (e.g., down the page) one after another. The paragraphs will occur in the same order as the cells are defined in the document source. Cells should make sense when read in order and should include structural elements (that create paragraphs, headers, lists, etc.) so the page makes sense after linearization". Having also provided you with examples of problems with data tables when linearised, I think I'm well within my rights to disagree with both your opinions that linearisation of data tables has no accessibility implications, since the only evidence you put forward is that F49 only applies to layout tables. As I said, I'm happy to work with you to improve Knowledge, but I doubt that I'll agree that WCAG 2.0 is the sole repository of all wisdom on accessibility, when it is clear from practical example and 6610:. Would you raise the same objection if it output 'AH'? There is nothing confusing for a user to hear (or see as a tooltip) "Ace of Hearts" instead of 'A♥', nor would it confuse a search engine. I don't see where you get "2" from, but even if we were considering '2♥', it's worth noting that the character '2' is a label for the "Deuce of Hearts" and has very little actual relationship to the numerical value 2 - it is merely coincidental that the abbreviation for the deuce/two is a character that is recognisable as the same thing. Try your logic on 'K' and tell me it's not an abbreviation for "King". I have nothing against using an icon with alt text (other than a preference for text over images that could be rendered as text, and the associated unnecessary byte overhead), but what icon are you going to use for "Queen", which would otherwise read as 'Q'? -- 5177:

area. I'm deeply committed to it, and would be happy to help someone else with a how-to in any way possible. I would describe myself as a user not directly affected by accessibility issues, but conscientious enough to take the principle seriously, technically adept and determined enough to find ways of accomodating the conflicting desires of functionality and accessibility, bad enough at writing that I do extensive work on tables, assertive enough (sometimes through articulation, sometimes through more abrupt methods) to get the apathetic to take a considered look at an idea, and, although I'm certainly not known for it, humble enough to ask for help when my knowledge simply won't cut the mustard. If anyone has suggestions on how someone with those attributes could help this area on a wider scale I'd be extremely interested. Regards, --

5640:(dd) elements that may contain block level elements – so no need for line break (br), as paragraphs (p) are usable (and are recommended by HTML3.0 on). So as you can see, the definition list is actually a very flexible structure used to associate elements without having a hierarchical structure such as headings. It may well have more applications on-wiki than you first think, but of course we are limited by wiki-markup. Properly used definition lists don't present a problem for accessibility. As for the way that the wiki-markup is rendered, I partially agree with you, but as layout it really should employ classes to delineate each element rather than (b/i/etc.) tags; this would allow for different skins or for registered users to override the default rendering as required. I guess that's another issue to sort out later. -- 8161:"A separate page may be the answer": that's actually what I had in mind all along. Many thanks to WCF for making it clearer. :-) That's what I had in mind when I wrote the first post of the section: "We will encourage to make simple tables (and avoiding rowspan/colspan when relevant will be a part of that). But it should not be an accessibility requirement." First we need a detailed tutorial on a dedicated page explaning how to produce accessible tables. The top of this page will contain accessibility requirements that are top-priority and simple to do. The rest of the page will be advanced techniques or "bonus guidelines". Basically, "bonus guidelines" are recommendations that do improve accessibility but are no priority and/or difficult to apply (for example, difficult to have the editors accept the change). 8285:

information where both are present in the same column. Linearisation of the data table produces the same result, but may be easier to test for. Either way, my demo table fails RNIB, and you need to recognise that even if a particular problem isn't listed in WCAG 2.0, it can still exist. SC 1.3.2 applies throughout and you're not entitled to guess that data tables are an exception, when there's no evidence of that. The problem is that I show you an example of a data table that fails to provide all its information when rendered via a low-bandwidth browser, and you say "It can't be an accessibility issue because WCAG 2.0 doesn't specifically say it is". I don't need references to tell me how to think, as I can recognise a problem when I see one. I guess we'll just have to agree to disagree on that.

7665:(equivalent to a 2-dimensional list), any user agent that linearises the page content will need the table to be written in such a way that it can make sensible decisions on how it produces its output. Failure to write the table in such a format restricts the accessibility of the page for anyone using this kind of browser (user agent), whether or not F49 explicitly says so. You could argue that Lynx needs to be upgraded (in the same way that text-to-speech agents need to), but until that happens, I'm opposed to any guidance that does not encourage editors to consider the possible impact of their table designs on partially-sighted users and those who have insufficient bandwidth to use a graphical browser. To me, it is abundantly clear that it is an accessibility requirement. -- 2943:, so I typically say it's been a guideline since before May 2009. Let me also note, that I have found similar widespread resistance to almost any changes in WP: this place is not a collegial dream of friendly collaboration. There have been numerous stubborn people, for more than 5 years. Anyway, has anyone written an essay, "Introduction to accessibility issues" which could be used to alleviate the initial resistance to caring about WP:ACCESS? Would an essay even help to reduce the severe opposition? I have learned that seniority does not sway many people: a person with 25,000 detailed edits gets little more attention than someone with 200 edits. So, I wonder about other ways to get people to become more cooperative about WP:ACCESS. - 8298:

is not available. If you don't care about linearisation, then don't bother – it is rendered fine on Lynx (but try looking at it on a mobile phone browser if you want to see an example of the problem). Pretty much the same applies to the other tables. I'll also add that "style=text-align:right" is more or less useless when you have differing number of decimal places in the data (proportional fonts don't help either). Keep the number of decimal places consistent and wait for CSS3 when you will be able to have "style=text-align:'.'" to align at the decimal points. At present it's also just one more hard-coded style to find and check when the page is translated between left-to-right and right-to-left languages.

4507:

I'm sure there are examples of rowspan where it would be far harder to avoid using it. On reflection, this change is a good thing (although it will require a bit of education to wikipedia's army of list designers, myself included). But knowing the way the Manual of Style is applied on en.wiki, sooner or later this will become compulsory. I appreciate that you may not have the answer, but I'd like to know whether implementing this change for rowspan/colspan tables is detrimental, irrelevant, or to some extent beneficial. If it's the former, we should probably explicitly list it as an exception, while making clear that rowspans and colspans should not be used if they can reasonably be avoided. --

12304:: I made a separate section to discuss the guideline you enforced at the talk page, as it played a significant role in this affair. To answer directly your question, some users will refuse part of the accessibility improvements we will advocate. In this case, it's important to not fight over it and to make the consensual changes first. From what I understand, you proposal - that contained other valid improvements like the addition of scope tags - was refused because of that number in the first column controversy. I suggest you remove this change in your proposal, and I bet you will have no more trouble to improve this article. Kind regards, 4781:

days of using table for layout purposes. It is unfortunate that tables persist in this manner on wikis; this is largely due to wiki-syntax not natively supporting things like div-elements and ol, ul, and dl elements other than implicitly. rowspans quite regularly confuse ordinary editors who do not really get what they're dealing with when editing a mucked-up table; they have a hard enough time with the curlies and pipes. Rowspans are also incompatible with sortability, which I see as for more important. I'm up for more work re this; I'm doing a lot of it out there on the 'pedia, anyway. Cheers,

4806:

images in tables or colspans, both of which are frequently used in FLs past and present. As I said in my edit summary, it is one thing to detail something as good practise (as this page used to do). It is quite another to make a practise manditory for our highest quality articles (as this page now does, being part of our Manual of Style). The information doesn't require inline citation, but at the very least it does require a broad consensus that the problem exists, and agreement on how the Manual of Style should tackle it, bearing in mind the way that the MoS is applied. Regards, --

11857:

with your opinion of how things should be done. I didn't ask you to comment on my example, but you felt you had to anyway because you thought you knew better. Well it turns out that you don't; your position is utterly worthless in a Knowledge discussion, and your capabilities are clear enough for anyone to see above. Now you have a choice: you can keep on provoking me by making things up, and I'll keep showing you where you're wrong; or we can bury the hatchet and get on with the real work like the horizontal list template. Your call. --

11481:

table structure that everyone is already familiar with. To some extent, it's a circular argument: most editors don't structure the data they provide, so they don't understand lists, so flatlist doesn't get used, so nobody sees it, so editors don't learn that they could use it to structure data, and so on. It does have a niche use already in navigation templates, and the potential to be used more exists. I see no problem in recommending its use where appropriate, e.g. in collections of variable length lists like this:

4705:, I think it's an appropriate use of rowspans, but maybe it's just that I'm used to it. If a screen reader user navigates the table properly (and most modern screen readers have reasonable table support), the meaning of the table should be clear. However you bring up a good point that navigating the table linearly is confusing when it uses rowspans. Even if a blind user is using a decent screen reader, they may not know how to use it efficiently, so they might effectively read tables linearly, no matter what we do. 5079:

reason to keep doing this wrong. This guideline needs strengthening, not cutting down. I cut rowspans from tables everyday, and for good reasons. Consider sorting, which is damn useful; it doesn't work with rowspans and that's unlikely to change. While not exactly an accessibility issue, it is an MOS issue. Throw in that rowspans confuse heaps of editors on a daily basis, and we've a solid set of reinforcing rationales to largely deprecate their use site-wide. There will inevitably be some exceptions, but damn few.

5890:, everyone can see exactly what you want to change, and unrelated points can be discussed separately. Once consensus develops (or doesn't) for the first change, you then put the next proposal out. The downside to this incremental approach is that it requires some persistence and organization on your part, since you'd need to keep feeding revised sections to the talk page slowly, over time, instead of making one big push. OTOH, I think it has a higher rate of success, with less drama. 35: 4575:. I'm not sure if this is what you mean by improper/missing row headers, but I'd be interested to hear your comments on whether you think that example is an appropriate and accessible use of rowspans. Whatever recommendations are employed to improve accessibility, they need to be simple, otherwise most editors will ignore them. It may be over-simplistic to advise against all use of rowspans, but IMVHO, it goes a long way to making tables more accessible in the present circumstances. -- 521:*smacks forehead* Thanks for pointing that out. I skimmed over the talk page, but nothing jumped out at me as being about adding links to section headers. For what it's worth I do tend to agree that the discussion about JAWS is not particularly relevant today, especially since the developers have apparently updated their software... still, the point about not using wikitext in headers is for everyone's benefit. Using links or templates in section headers makes it difficult to create 5097:

it would be counterproductive to explicitly say that they should not be used for that purpose, if we are definitely going to an RfC in a few weeks. At best it would make no difference, at worst when someone tried to apply it someone else would challenge the whole thing, starting an RfC before we're fully prepared. I've underlined the suggested compromise above. Finally, provided that the message is clear, the length of a guideline is inversely proportional to its use.

8681:

keyboard as does Opera 10.61. Frankly, I would not be comfortable disadvantaging such a substantial proportion of low-bandwidth users. At present redundant links are easy and solve the problem, so must be recommended. It is not acceptable to insist users change their preferred browser when a simple solution is available. In addition, many users (both corporate and in public locations) are "locked in" to a particular browser by windows policy (see

8195:)? It's rather easier to read than WCAG, and although it is less up to date than WCAG 2.0, it represents an approach derived from their experience with users, and it does specifically refer to Lynx as an example of a text browser. It's true, of course, that as broadband coverage increases globally, a smaller proportion of readers will be viewing with text browsers, but we're still a long way from being able to assume text browsers can be ignored. 4853:

return to normal viewing. The following is clear: (i) rowspans in particular jumble information when read linearly; (ii) simpler screen readers do not cope well when either row or column headers are spanned; (iii) having an image as a row or column header causes problems unless it has sensible alt text. I simply don't see why we should second-guess the inconvenience that these sort of issues may cause, when the simple solution of

5016:

row/col spans is quite off as 'simplifying' tables with them is the core of accessibility issue; it entails simplifying the rendered appearance of a table by increasing the implementation complexity at the expense of accessibility and functionality (specifically, by precluding sorting). The solution to the rowspan issue is simple and at hand; don't use them in most cases and simply give each cell the appropriate content.

9096:"Guitar", "Vocals", "Drums") for each quarter where the member was part of the band - and then remove the column "Primary Instrument", which would make the table more compact. I'd also prefer to see an annotation (e.g. "*") or linked group ref (appearing as ) to indicate current members. Taken together, that would remove the dependence on colour. Have a think about it if anyone is intending to create a table. -- 8323:. The changes result in advice that has no rationale and requires the user to look elsewhere for its requirements. That does not make it clearer. In addition, it is disruptive to implement changes while they are under discussion. I don't agree that there's agreement to remove cautionary advice on the use of row/col spans. It is undeniably true that they can cause problems, and editors need to be aware of it. -- 8652:. Safari 4 did not support it, but it's now outdated and will soon be almost unused. I did not test with Chrome (but since it's Webkit it should be fine) nor Opera. Anyway, the two major browsers have keyboard support for those imagemaps. And you admitted yourself that major assistive technologies support imagemaps as well. It's the responsibility of the users agents to have keyboard support for imagemaps. 9177:), and with the Excel spreadsheet from which he made the timeline. Among many other considerations, I'm sure the timelines that start before or after the end of a year were generated by Excel from underlying dates, which would be quicker and surer sources than eyeballing an approximation from the graphic image. Perhaps a suitable adaptation of the Excel's code ("View Source") could serve as the alt-text. 8731:. Explain how a Lynx user can get the information from the second table there. Tell me why we should allow either of those tables to become garbled when viewed on a mobile phone browser. Find me an real expert who will justify disadvantaging numerous viewers simply on the grounds that WCAG 2.0 fails to specifically mention the issue. I'm deeply disappointed that you only seem interested in attempting to 5794:

what they see. It only takes one example for them to copy if they register, and it works on all of our pages. It's not difficult to make headings bigger or bolder or with more space above them if that's what they need, as long as we mark headings as headings, and not just as large or bold text, etc. The same sort of thing goes for paragraphs, lists, wikilinks, etc. It only takes a single line like:

2911:(for WP:ACCESS), so it now looks balanced at 800x600 (or even narrower). There was some strong resistance, but I am finding resistance to WP:ACCESS everywhere because the Firefox browser seems to keep boxes wide, while only MS Internet Explorer 6/7/8 tends to squeeze other text or Table-of-Contents boxes into 2-words-per-line at 800x600. Eventually, it was understood to affect IE's narrow boxes. - 5588:. And this very article uses it incorrectly: tons of "definition list" (DL) containing one item (semantically bad); several "definition descriptions" (DT) per element instead of one (should use BR to make a new line instead); and no "definition term" (DD) at all. Seriously, what the fuck. It will be nearly impossible to get a good use of it on Knowledge (but it has a great future in Wikitionary). 12278:. There's still the minor issue of putting a number in the first column and marking up the name in second column as the row header – but it only causes problems for older screen readers that don't understand the markup (they just speak the contents of the first column as their choice of row header). It's not worth going to war over, and I expect time will solve these problems for us. Cheers, -- 7715: 657:

do, that it's simply best to avoid markup in section headers, then I wouldn't say anything about it. However, it's my sense that most tend to agree. It would be helpful to have the actual technical limitations written down, but I think that there is a style and usability issue mixed in with this as well, so simply clarifying what is or is not technically acceptable is not the end of the issue.

10840: 10181: 2580: 317: 3446:" for some fascinating insights about literacy in blind people who only "read" through audio technology. The sample story written by the sixteen-year-old blind kid about "sleep bombs" is hardly a paragon of good spelling or grammar. I myself am a good speller, but that is partly because I've read Braille for most of my life. I often rely on Google to confirm the spelling of words, and 12443:

would be nice if others were willing to go to the trouble to reorganise tables to help a small number of visually-impaired viewers, but I don't think it's a productive use of our time to fight those sort of battles, unless it is blatantly obvious that such changes could be easily accommodated (e.g. ! Title | Year | ... is far more sensible than | Year ! Title | .. for song releases).

11665:

lists in regard to headings; having raised that very issue with the WHATWG working group in the hope of rectifying the situation in HTML5, but that doesn't negate my point; and nor do false comparisons with tables. List mark-up is correctly for lists of items of equivalent type not such items plus headings. But these are side issue which shouldn't detract from the job at hand.

10234:(which are appropriate for screen readers and also allow alt text to be used), I wondered if this was a useful opening for a more open and extensive review of symbols that could/should be used along with clear discussions over whys and why nots? The easier we make this for folks to implement, the more likely for it to be accepted at places where this is most prevalent, e.g. 1930:

the rest of the article body. I searched this talk page's archives for previous discussions about table readability but the closest discussion I found was font size in "References" sections, which I personally find secondary to the article body. Does anyone know if discussion has taken place elsewhere about this and if this is a real accessibility issue to investigate?

1419:) without making the whole page tedious and unmanageable. There are also collapsed portraits of several royal families. If this really causes a major problem for visually-impaired readers, we need to go back and think out how best to present the information. ¶ I don't want to print out reams of paper, but I'd be glad to do a quick visual test the next time I open my 9067:) that convert Excel spreadsheets to Wikitables. What I'm wondering, as a complete ignoramus in both accessibility and software coding, is would converting the spreadsheet to wikitables (1) require fewer kilobytes of code and (2) be more easily readable on an accessibility device? (for all of its refinements, this table doesn't seem to use much colspan or rowspan.) 12352:: you supported the proposal about the numbers thing. Since there is no guideline about this case, we should discuss this guideline at the accessibility project. Discussing a guideline among editors that are supposed to apply it doesn't work, as it only add to the confusion. It's my mistake, I should have asked to discuss this issue at this WikiProjet immediately. 1009:

all but very short pages, link to text with no heading in most browsers, because the heading will be scrolled up above the viewport. I imagine that it's even worse for screen readers, with text being read without any indication at all that this is actually a new section and the heading for it was missed by one line. This stuff is an accessibility, usabilit

9713:"Ensure that color is not the only way used to convey important information. Especially, do not use colored text unless its status is also indicated using another method such as italic emphasis or footnote labels. Otherwise, blind users or readers accessing Knowledge through a printout or device without a color screen will not receive that information." 1603:? I've tested both articles, and only the Victoria and Albert one caused problems (behaving exactly as you said). I suspect the issue may be with the template syntax, rather than the collapse function specifically. A test worth trying would be to remove the collapse function from one of the family trees (temporarily), to see if the print preview works. 5451:, which an appropriate semantic structure for what I was doing. That page and, many others, do not need separate section headings for two bulleted bits of boilerplate. You have been far too bold in pushing guidelines, help pages and such about for one so inexperienced here. Fair warning: I'm about to start clearly calling you a disruptive editor. 5465:

edit to this guideline that '; ... :' is not interchangeable with headings, nor as a means of emphasising a piece of text. You're quite right that a definition list has a place in semantic structure, but it's a point that is not immediately obvious to many editors, and it's our job to help clarify that. I do believe that the MOS guidance at

8093:

editor could object to the addition of good alt text to an image on the grounds that it isn't required, because editors are now much more aware of those accessibility issues. We want to move away from the position where editors place aesthetic considerations above improved accessibility because they are not aware. The aim for Knowledge

4100:. As I suspected, there is another issue with these kinds of tables. I'd be helpful to have row headers, but currently the "Album details" column is too messy to allow that. It wouldn't be very helpful to make years row headers here. A correct row header in this case would be the name of the album. I suggest to rework it as follows. 5508:

was a bad one, as were several others related to discographies. Far too many editors bulk-up TOC with too many minor entries that simply don't warrant being any level of heading, and this is where structures such as definition lists step in. Table captions, too. Dodoïste's revert (and proposed) change to the guideline both refer to

3893:: this is the kind of tables an accessibility expert (also admin on the french Knowledge) recommanded to make in his list of best practices. This is also recommanded on websites with a lot of expertise like WebAIM. We should use this syntax from now on, and correct tables using the previous syntax. Thanks for your help. Yours, 12255:. Perhaps it would be useful to explain the problems (in very simple terms) at the actual WikiProject page and inquire whether the project's actual members really are determined to make their articles less accessible to people who use screen readers, or if the editor in question is simply arrogating veto power to himself. 10431:, but was disappointed to see that it still uses a text symbol: ♠ – which we know is read as '?' by JAWS. I think that some debate is required at the talk pages of the cards templates to see if there's any reason that an image + alt text (like "of Spades") shouldn't be implememted. If that's done, then I think a category 10501:– as you can see, the antialiasing required to make curves at normal size turns into fuzziness as the browser zoom is increased. It did the same with the anti-aliased dagger, but I was able to make a plain version of that without any curves or diagonals, and that's not possible with a spade symbol. Any thoughts? -- 8634:). Even if WCAG 1.0 is now outdated, us old-timers can still recognise where it's useful, and in this case redundant links solve Gnevin's problem. My advice: don't dismiss WCAG 1.0 lightly; if the techniques there can solve a problem that WCAG 2.0 doesn't address, don't be afraid to use those techniques. Regards -- 8361:. You make a bold edit and I revert it; that is where it sits while it is discussed. Now, if you want to learn how to work the Knowledge way, you'd best strike that nonsense "Until we reach consensus it shall be removed", as that will be construed as a declaration of your intention to force through your change by 8704:. W3schools stats are representative of browsers usage among geeks / developers only. I also said there is nothing wrong with those redundant links. It can be a bonus or something. But unless you find an up-to-date accessibility guideline which recommends to provide redundant links we won't recommend it either. 11151:

alt text, but I think it's a little odd that Commons images shouldn't have some default alt text. This may have been discussed before, and perhaps I'm asking for the impossible, but how good would it be to know that anything coming from Commons has something for screen-readers etc without worrying about it?

12442:

If we swap rows so that the row headers become the first column, we cater for viewers using older screen readers that don't recognise anything other than the cells in the first column as row headers. This is an issue that will diminish over time as viewers replace old software with newer versions. It

12341:

compliance. There is no guideline in this manual of style - nor in the data tables tutorial - that support your claims at American Idol (season 10) talk page. You assumed that there should be absolutely no numbers in a row header, based on a guideline for a special kind of table. I tried to tell you,

11664:

Please don't confuse criticism of the example with an insult to the provider of that example. The former - unlike your fallacious allegations about what you imagine or would like to think I cannot see - is not a personal attack an is perfectly valid comment. I'm familiar with the limitations of HTML

11150:

Hello ACCESS. I wondered if anyone had considered asking Mediawiki (or whoever) to implement a "default alt text" that could be set up at Commons which would provide a default alt text comment for all images there? Ok, so images uploaded to Knowledge (e.g. fair use) would need some local addition of

10803:

Although keyboard shortcuts are related to accessibility (all operations that can be performed by a mouse must be able to be duplicated using the keyboard alone), I agree that they have no relevance to the guidance we want to see given to editors at WP:ACCESS. I'd recommend that the section is simply

9678:

The guideline "do not overlink " has nothing to do with accessibility, so I've bluntly removed it. I understand that a collection of links in a sentence makes it tedious for a screen reader user to read the sentence. And overlinking happens often on Knowledge. But overlinking is not an accessibility

8726:

We don't need to be accessibility experts to make our own guidelines. No matter how much you blind faith you put in an external guideline, it cannot substitute for the process we have developed on Knowledge. Discuss the issues and make your case. Show me how anyone using text-to-speech can understand

8722:

If user agents have not yet been improved, yet you refuse to accept that their users should be considered, how else is anyone to interpret it? Each website's stats are naturally only representative of their audience, but I pointed you to W3Schools because they show the proportion of their viewers who

8275:

RNIB's "WAC See It Right Standards" gives background information and guidance on their audit process. Although RNIB is an active member of W3C, it has different emphases from WCAG (and produces more accessible documentation!). An obvious example of a criterion removed in WCAG 2.0 is RNIB's "14.1: Use

8167:

Not relying on a person's supposed expertise or background (which is impossible to verify) is fine when we rely on references. We don't need to rely on a user's authority because we have verifiable sources from experts that provides all the information we need. But is it the case here? So far I'm the

8116:

is part of the Manual of Style. The intention for that change was a good one- to give ACCESS more clout. Unfortunately that's a double-edged sword. Given that anything that goes on here is as near as makes no difference manditory, the burden is on editors here to persuade the wider community that the

7977:

have far more experience in dealing with their members' feedback; one of the big criticisms of WCAG is that they do not seek sufficiently broad feedback from actual users. Look at how long it took them to update WCAG 1.0 to WCAG 2.0. Let me add one question - would you write the following table using

6275:

I've had a go at simplying a few accessibility changes specifically for music editors and I thought the completed essay could be distributed amongst those in the community. Since i know many of the high profile editors I thought that if they saw me adopting the policy it might have a knock on affect.

5725:

What if the purpose is not actually to create a header, but to visually break up an oblong gray blur? Several readers with dyslexia have complained about long articles on Knowledge. Liberal use of color (which we don't do) and text formatting (which we can) can make articles more accessible to some

5683:

Bold should not be used to make visual headings because users without sight won't recognize them as headers. The ";" element is often used for the same purpose, which should be avoided as well. Note that ";" is meant to produce a definition list, and when correctly used it can be a great improvement.

5552:

was a few months ago. Basically, after months of endless debate a clever user hopefully requested an accessibility expert to comment this guideline. He basically said they had it all wrong. Afterwards, the guideline was rewritten completely according to the expert's advice and is now fairly good. But

4992:

It's not perfect, and may need to be strengthened or considerably altered in the medium-term. But while it would be wrong to mandate against these things without having a firm understanding of the problem and a good grasp of the solutions, to remove all reference to these issues isn't good enough. On

4892:

different. But any wording needs to take account of the fact that the MoS is treated in some quarters as canon law. It also needs to accurately reflect the problem, so that editors without screen readers can accurately gauge whether a particular use of rowspan/colspan (from my experience usually only

4790:

Sorry, but this is not really helping. We need detailed sources or advice from experts. We need examples of accessible tables. We need alternatives for tables using rowspan/colspan when relevant. But we won't be able to do anything with opinions like "sortability is good so rowspan/colspan are evil".

2185:

I don't need to look it it up in the MoS, I know the sectiojn almost by heart - the differences, without any personal bias or offense whatsoever, between AE and BE happen to be a 30-year professional specialisation. I would willing rewrite the short sentence for cultural neutrality and

1343:

Can you provide specific examples of the problems you mention? As I noted above, I experimented with two browsers to see if there were any printing problems and discovered that the collapsible content simply expands when printing. What specific problems are you aware of with printing? I would like

525:

links (wiki-links), let alone actual HTML anchors. If that isn't a good enough reason not to, the fact that there are a good number of (some very) old browsers, and some intentionally simple browsers, used to access Knowledge ought to be a good reason to keep the point. Besides, the stricture against

9537:

I moved your section here, because it is written as a debate/discussion rather than a guidance. And while the point about transparent backgrounds seems sensible, it is not part of any accessibility guideline I know. And I'm not sure its priority is high enough to dedicate a lengthy section about it.

9525:

Webpage color is not determined by the website. Browsers and operating systems can and do override the page settings for accessibility reasons, e.g. making pages white text on a black background. It is a fundamental feature of the markup language HTML that webpages should be readable on any platform

9132:

The example in the picture tutorial is accessible (except for a few browsers bugs but it's arguably not our fault). Now using this technique to make a meaningful table... If even possible, I bet it would be really tricky and fragile. Imagemaps are not meant to produce tables, so I'd rather encourage

8171:

A while ago I showed you F49 about layout table linearization. You replied that I was half wrong without providing references. An accessibility expert confirmed what I said and provided details. And you kept on disagreeing. I don't bear the slightest grudge towards it or anything. However, if we are

8073:

Thank you for your assumption of good faith. I believe both you and Lgd have only the best of intentions, although I have already demonstrated where you are going wrong. I'd be grateful, though, if you would stop making appeals to authority that does not exist on Knowledge. You have no idea whom you

6591:

is nowhere near an abbreviation. And it would be confusing for the user. Last time I asked Graham87 about it, he told me the abbreviation is displayed on demand. That means he first has to know that the content is an abbreviation. In this case, the only spoken content is "2". And "2" is not supposed

5748:

Isn't that a solution looking for a problem? Well-written articles will already be broken up into sections with headings; sections broken into paragraphs; judicious use of images, lists and tables further break up the block of text. Many of these already have classes associated with them that can be

5733:

These features can solve a problem that only affects sighted readers. Not flagging those could not harm the non-sighted readers, as they don't need this kind of help. So -- why shouldn't we use bold-faced text on occasion? Why not use purely visual cues to solve a purely visual problem, when that

5476:

Dodoïste, you may not be aware that edits to policy and guidance on en.wikipedia are slightly different from edits to mainspace, as there is a conventional requirement for a greater degree of consensus for such an edit. If you're unsure, I'd always advise bringing an issue up on the talk page first.

5306:

None in particular; I don't use a screen reader myself. I just want to know what the "best" wiki markup for fractions ought to be, all things considered (aesthetics, accessibility, etc.). I have no problem with ½ when viewing a page (although it looks terrible in the edit window font), but I see a

5029:

We cannot state that they should not be used though, because the evidence is lacking. Even if evidence is found, it's clear that there is no consensus to ban them; a quick glance at sitewide practise, even on currently nominated audited content, shows that. I've strengthened the wording to take your

4957:

I'm very happy to add an accessible tables tutorial to my to-do list, although it would be a medium-term project. Estimated timescale: 3 weeks to get my head around the conflicting issues of a desire for maximum functionality, total accessibility and as little disruption as possible (it won't really

4953:

Jack, I understand why you did that, but I don't see that as being particularly constructive, bearing in mind that this dicussion is very much active. Furthermore, I certainly don't see Dodoïste as having an "agenda" (it could be argued that I do, but I engaged in discussion first, and it's Dodoïste

4860:

It's worth remembering that MOS is a guideline, and some exceptions are justifiable, but it puts the onus on the editor to consider these issues; it is not blanket ban on the use of particular elements. We do a disservice to impaired users by assuming that they should be forced to adopt our ideas of

4780:

Hi. This is an interesting thread. I'm down on rowspans for a number of reasons, including the issue that RexxS has the subpage for. rowspans confuse a lot of people and a lot of software. It is a false optimization to combine data cells this way. A lot of the history of rowspans is from the bad old

4437:

Although concerned about getting to grips with this, I support the basic principles behind the change. But twice I've read the data tables section, and twice I interpreted the limitations at the end as suggesting that colspans and rowspans should generally not be used. If this is indeed the case, it

3646:

It's not a big deal to me; it's just a minor inconvenience to move between the columns to figure out which film the notes and other things are talking about. I'd admit that I navigated the table in a rather unusual way, doing things like going up and down the notes column. On a scale of 1 to 10, I'd

1834:

It's logical to move those quicklinks to the MOS, although it would be ideal to come up with alternative ones for WP:ACCESS. What I would like to do is move the "or to consolidate information already covered in the prose." segment into the MoS, on the basis that this is what infoboxes already do (or

1688:

If navboxes aren't accessible, that's a serious issue. I routinely omit "see also" sections, on the basis that the navbox covers it. If it doesn't, there needs to be quite a bit policy change about their use (wider than this talk page). Print preview isn't a problem, but are there other devices that

656:

Well... I've never really probed the limits of what is and what isn't usable in section headers. I just know that it tends to create problems, especially with wlinks, so I simply avoid doing it. It is kind of a neat feature to use, in some places, but... If I were the only one to feel the way that I

12345:

Lil-unique1, it's good to have people like you here, enforcing accessibility guidelines. And you can make mistakes, just like everyone does. But since you're here to learn about accessibility guidelines, if someone with more experience on the topic says "you're wrong", you're supposed to reconsider

12135:

Well I appreciate Rambling Man's comments... but I wondered whether the stance is that unless its a GA or FA/FL then it doesn't need to adhere to MOS. Its concerning that on the one hand Access is becoming more prominent in the MOS yet there is stiff reluctance to adopt it... Essentially I'm asking

11204:

it's used 97 times across all of English Knowledge. Is this really something we should be advocating, or is it something that has been superseded? I have seen horizontal lists, usually as part of templates, but clearly they rarely use this template. I think it's worth talking about, since MOS is

10019:

As you can see in the following sections of this talk page, we are doing some much needed cleanup to this guideline. As of now, I still see 2 advices that are not strictly related to accessibility: the section about screen resolution, and the paragraph about striketrough in articles. We'll complete

9529:

Putting transparent backgrounds on images mixes the content of the image with the style of the webpage rendering many images unviewable depending on browser and operating system settings, particularly if the OS is set to high-contast black and white then black equations, graphs, charts and diagrams

9004:

That's right RexxS. :-) We can hardly do anything better because of MediaWiki's limitations. So an alt text will do for now. More importantly, we should not remove images because they can't become fully accessible for now. Or else edidors might begin to hate accessibility or decide to ignore it. It

8680:

Firefox 3.6.8 with images turned off (via Web developer toolbar or via options/content/load images automatically) doesn't display any links for the image map, on both Windows and Ubuntu, (nor does Lynx nor IE6). IE8 8.0.6 with "Internet Options/Show pictures" turned off has the links available from

8297:

idea (in HTML, the THEAD|TBODY|TFOOT elements are available for long tables), because it annoyingly repeats that row on a screen reader. If you want to have a table that linearises properly, you need to put a value in each cell, so the "Chrome" column should contain something like "N/A" if the data

8092:

By the way, I don't think I can overstate the massive contribution that Eubulides made to improving Wikipedians' awareness of the importance of alt text. Not every editor has the skills to create good alternative text – and that is why it remains a recommendation, not a requirement. Nevertheless no

8088:

I appreciate your concern about placing a burden on editors, but it is a mistake to assume that this equates to not giving the advice. Knowledge is a collaborative project, and the shortcomings in one editor's contribution will eventually be improved by others if the goal is clear. There is no need

7889:

Many thanks for that, but I still have to disagree with over-reliance on WCAG; web designers also need to be able to structure data properly. I'm sorry to say that your example is poorly structured (even though it's a common form of presentation). There are two axes of information: level and number

7851:

Do you see why WCAG doesn't apply linearization criteria to data tables ? If you want data tables to be accessible when linearized, you're going to forbid the use of most data tables, even without any colspan and rowspan. Moreover, that will be wasteful for accessibility, because when this table is

7355:

in their arms/wrists, which affect about 1% of the population in most developed countries. Mouse work is often very difficult for people with carpal tunnel and such. Could we please go back to recommending against this, specifically for the purpose of providing maximum reasonable accessibility to

6052:

This discussion is predicated on the assumption that guidelines are prescriptive, not descriptive. Just as all articles are works in progress, so are the guidelines used to help construct them. When, as now, many more editors are becoming aware of the importance of accessibility and usability, some

5942:

to then be littered with a brawl of confusing and undiscussed changes as well as genuine changes to the MOS:ACCESSIBILITY. So here's a suggestion. First of all someone should create an essay about the imcumbent changes to MOS:ACCESSIBILITY and explain that wikipedia in general is undergoing change.

5793:

You're quite right that unregistered viewers (and that's a huge majority) and most registered viewers won't modify how they see Knowledge. They see whatever the editor presents to them. But if we're considering someone with an impairment, then it may be worth their effort to find out how to enhance

5525:

Dodoïste, you've already slipped the scope piece into this guideline and implementing that site wide as explicit markup is impractical, as there are literally many millions of table headings. The 'insert table' buttons don't generate this, so mostly it's not going to happen via this route. As said,

5464:

Take it slow, Jack. It's reasonable to assume English is not Dodoïste's first language, so the wording may not contain nuances that he intended, and so far nobody's stepped outside the bounds of our conventions on collaborative editing. I feel sure he was trying in good faith to make a point in his

5166:

behind than the current text. I also hold the belief that while our mission should be to strengthen this guideline, that taking a medium-term view is the way to get more meaningful results faster. Changes to this guideline only take effect when community consensus is with it. While we can change it

5126:

Images should be avoided in table headers, unless there is a demonstrable benefit to using them. If they are used, alt text and a key should be provided, to ensure that all readers can understand the information. The extent to which rowspan and colspan cause accessibility issues with screen readers

5096:

As for your comment about rowspans for the likes of years, I agree that it should be eventually be depreciated. But the fact that it is so widely used (even in audited content) very strongly indicates that current consensus lies somewhere between indifference and support for the practise. Therefore

5078:

That better, but it needs to be clear that rowspans and colspans should specifically be avoided in cases where it would be done to simply reduce repetition of information such as things that occurred in the same year (a common use; years are not the issue). That they exist in large numbers is not a

4805:

Apologies for leaving it for a while to post this, I was hoping that Dodoïste could explain the problem more eloquently. I restored Dodoïste's recent edit, which was reverted by RexxS. My understanding is that rowspan should be depreciated, but I've seen nothing supporting a similar depreciation of

4506:

I agree that there was no need for it there, but sometimes colspan and rowspan are unavoidable. For instance, in sortable tables colspans are sometimes used in lieu of breaking the table into sections which would negate the use of sorting. Although I really like your solution to discography tables,

3375:

it doesn't matter to screen readers (or to you), considering that page elements are read in a linear fashion, and I'd assume that if your computer doesn't support a particular language, you'd like a warning of why you're getting improperly rendered characters before it happens; but I don't know how

1450:

More data of what works and what doesn't would be very helpful. As I said above, I tried this out in both popular browsers and in a text-only browser and everything worked fine. If you have more data from different browsers or screen readers, that would be great. This will help drive an informed

12547:

Good to hear that you will stay around here. :-) I can seem to be harsh sometimes, because I feel the need to speak honestly about the problems that arises. I mean it as a way to be constructive, and to enable us to move forward. I'm not sure if it produces the effect intended, however, and if you

12198:

It is simply a truth that certain corners of the wiki have become "walled gardens" where small groups can own articles and decide for themselves the content and the 'local style'. In the case of American Idol, I have tried to explain how the accessibility of all of our articles should be a concern

11856:

I have made no false claims. You can't explain how to mark up a list header to indicate its relationship with the list, and insist on imposing your opinion that lists have to contain only homogeneous data. Then you have the gall to criticise another editor's work simply because it doesn't coincide

10967:

If there is general interest, I believe I could make something more generic. I agree that the linen color is not the best, but I was looking for something that would have enough contrast, but still be visible. Please change it to something else if you can come up with a better option! The basic

10700:

No, I wasn't saying it needed something passionate, just that the previous explanation, well, explained absolutely nothing. At least now readers without screen-readers will understand that the text is read out, sometimes in the language defined in the template. That makes a huge difference. And

9844:

Since JAWS 7.1 is now over four years old, the only objection to links within section headers appears to be the inconvenience of having a screen reader precede each link by a newline. That is clearly a usability issue, not an accessibility one. Removing this outdated restriction would allow richer

8981:

since it has no alternative text which would explain its purpose to anyone who can't see the image. In addition, a good piece of general advice is never to use an image to convey information that can be conveyed equally well by text. Having said that, it could be argued that the information in the

8707:

We are no accessibility experts and aren't able to make guidelines ourselves. Sight. For simplicity's sake we should blindly follow a published and up-to-date accessibility guideline. If we need to have lengthy discussions like that every day we will spend years over tiny annoying details. We have

8089:

to aim for a short time scale, as we have no deadline. By insisting that there are no accessibility issues connected to rowspan and colspan, contrary to ample evidence, you remove part of the incentive for those editors who have the technical and design skills to improve the presentation of tables.

6880:

doesn't actually contain icons at present, the lack of mention of that at FLC is hardly surprising. I still have a preference for not using images where text can convey the same information (albeit non-ascii text in this case). I still think text+title attribute is a superior solution to image+alt

5507:

Definition lists are one of the secret weapons of serious web developers ;) It's really a very versatile structure and there's a ref somewhere in the W3C spec that refers to it specifically as appropriate for a lot of structural use (not that that is what I was doing, here). The revert in question

5176:

As I say, I don't think my overall understanding is good enough to be a driving force in our attempt to improve accessibility, so with deep regret I'm going to have to step back from my previous intention of drafting a how-to by September. But I don't want this to be seen as backing away from this

5082:

I hear there's an 'expert' on wp:fr. I'm right here and have considerable real-word experience with this stuff. This should be brought to the attention of a wide swath of the community before and serious change is made, here. That would entail a healthy discussion and gathering of discussion point

5015:

I didn't mean much by my use of 'agenda'; POV or opinion would suffice. I've not much though on the image question in the above. However, images in lieu of text is poor form from a search engine optimization perspectives and a lot of accessibility issue track with SEO issues. Your rule of thumb re

4969:

be avoided in table headers, unless there is a demonstrable benefit to using them. If they are used, alt text and a key should be provided, to ensure that all readers can understand the information. The extent to which rowspan and colspan cause accessibility issues with screen readers is currently

4928:

I've just reverted the cut you made re rowspans and the undiscussed addition re bold. You're being entirely too bold at editing these guidelines as suits your agenda. Please cut that out an discuss changes prior to editing the guidelines. The "scope" changes should probably be cut while discussion

4700:

In developed countries, it's usually possible for blind people to access the technology they need (i.e. a good screen reader, a portable computer), especially if they're either studying or working. As noted above, NVDA is a good free screen reader, and as far as I can tell, its Internet support is

4648:

make use of the simpler assistive technologies, and it is important to recognise that. Please understand that testing with a screen reader is not a substitute for making web content accessible for the blind, but it is a very real consideration for many other visually impaired users who wish to use

3289:

templates go after the infobox, but doesn't address foreign language templates. This is a hold up at FAC: can we please get a reading from editors with screen readers, and have this addressed on the ACCESS page? I personally think putting the chinese text template first is butt ugly, but if it's

3186:

They do, but you have to explicitly tell them to inform you about attribute changes. By default, screen readers won't mention any attribute changes at all (e.g. bold/underline/italics/strikeout), but when a key combination is pressed, the screen reader will say the attributes of the text under the

2090:

I notice that this article, like many, is advocating American supremacy over British English. The language was written in good faith, but good faith, however innocent, can deeply offend. I would carry out the necessary edit myself to neutralise this in a reasonable manner for it to be

1929:

attribute. I personally do not mind this attribute, but I am concerned that this minimal adjustment affects accessibility in terms of readability. Such tables are major parts of the article body, and it seems detrimental to display their contents in a font size smaller than the font size used in

1189:

as it is currently written is overly cautious and possibly outdated. I admit I have not completed an extensive test pass (yet), but I have seen enough so far to come to at least a preliminary conclusion that this section in the MOS needs to be updated/rewritten. Given that this is the first time

1008:

important that be able to reasonably link to sections, often under shorter or previous names for them. Anchors above a heading become part of the content of the preceding section, and may disappear or move with that section, which is a fatal problem for that usage. Anchors below a heading will, on

803:

The only real technical issue with this sort of thing, that I'm aware of, is that the template wiki-text makes it nearly impossible to wiki-link to the section header "normally" (ie.: without using the anchor itself). For a good example of misbehavior along these lines, try linking to an item on a

11649:

I beg to differ. It's an excellent example. HTML does not have markup for the semantic equivalent of row/col header in the implementation of a list. It does for a list of lists, i.e. a table. I don't see you criticising headers in tables just because we mark them up as elements of the table. If a

11460:

Hang on, while I agree that it could be improved (in whatever timescale), we should not be recommending the use of a template which is problematic. Given the number of usages, (and I'm still hoping someone can provide me with a good example of a featured list or article where this is beneficial,

11322:

Problem with this template is the the bars that it generates to separate the items do not look vertical and causes problems trying to read it for some sighted users. This is more evident on very shote items where the separators are close together. This needs to be addressed before the template is

10818:

Keyboard shortcuts, in the way they are implemented on Knowledge, are useful for some users with disabilities, and bothersome for some screen readers users because it interferes with the shortcuts of their screen reader. The best solution would be to have costomizable keyboard shortcuts. So, some

10557:

The "similar reasons" is a little unclear to me, but I guess it's because screen readers (for instance) would read it out in a different section from that intended by the fully-sighted editor who put it there in there in the first place? If so, could we clarify this explanation a touch? Perhaps

9763:

If italic text is used in a table, they're should be some explanatory text saying "these items are in italics" or whatever, then screen reader users would know to search for the italic text, or tell the screen reader to announce formatting changes. Screen readers can also identify the colour of a

9495:

Why do images use a transparent background ? So that they merge into the surroundings on any page, no matter what color the page is using? But images themselves have colors in them, so images with transparent backgrounds cannot be used on pages that are colored with the any of the colors that the

9205:

I didn't feel like dealing with the semantics of getting precise dates for everything, hence my choosing to deal with quarters. I did find the dates in the wiki article, then made changes by quarter and forgot about the exact date. Everyone is right, it was done in excel. I considered making it

9095:

I suspected that it was Excel, and agree with Dodoïste that a table would be much better for all sorts of reasons. It would need a little reorganisation because many of the cells carry their information purely by colour. My inclination would be to fill them in with 'B', 'G', 'V', 'D' (for "Bass",

8985:

My initial view is that the image only provides an overall summary of that information, which is a bonus, but unfortunately presents it in such a way that it is inaccessible for those who cannot see the image. Whether or not that is an appropriate use of 155 kB of article content is probably best

7371:

I'm not sure I understand your proposal. If you suggest to bluntly remove collapsible boxes and scrolling lists, I'm afraid it's a bad approach to improve accessibility. We must not reduce the quality of the content in order to be accessible. If you are proposing something else, could you provide

5503:

that Dodoïste is a she. My reference to their edging towards disruptive editing is rooted a few points; changing a guideline and then quoting that guideline as a rationale for a revert within a minute is plenty to give one pause. They've aggressively edited this guideline without prior discussion

12517:

Don't worry RexxS it takes more than this to discourage me... I know I only write song-related articles but all of my song articles use scope formatting where possible. Additionally the discographies I work on also use this formatting. :D That's my contribution. Hopefully people respect my small

11480:

Well, it's obviously useful when we want to present a list all on one line. I mean, its purpose is purely presentational as an alternative to using the * wikimarkup on consecutive lines. The reason it's not used more is that the best use would be to make a list of lists - and that equates to the

9318:

Half of the tutorial has been reviewed by an accessibility expert and I made most of the corrections already. Which means this tutorial has reached its final form. Now is the time to comment its content. If you disagree on something or don't understand a guideline, please do tell about it on the

9154:

Image maps with proper alt text will be accessible for visually-impaired readers who use screen readers, and many modern browsers will supply that text even when images are switched off, but they do present some problems with a few modern browsers and many older browsers. If we also consider the

8611:

tag are not keyboard accessible (tested only with Safari, other user agents may behave differently). I said this template is accessible because Lgd said those uses were correct. But maybe it's not fully accessible and it's simply the best we can currently achieve. I'd be best to get some details

8243:

Those quotations from the guidelines are not enough of a proof. If data tables need to linearize correctly it would have been stated clearly. SC 1.3.2 is high-level and data tables may be the only case where it doesn't apply. It is not stated anywhere that the definition of "linearized table" is

8239:

I had a quick look at RNIB's guidelines. Lgd told me the RNIB does not promote nor use any criterion that isn't part of WCAG. Basically, they didn't add any criterion in their guideline. The RNIB doesn't invalidate – in their audits criterions – any use of colspan / rowspan nor any linearization

8138:

It's worth regularly reminding other editors that, contrary to popular belief, MOS is a guideline, not policy (and for good reasons). However, I agree that MOS is often treated as mandatory, and I support all attempts to give ACCESS more clout. It is clear to me that the underlying principles of

7934:

Now, you can see that each row has a unique header, and the numeric data is solely numerical. This is an important principle (as you have already stated on your user page). The table will now linearise into an understandable format (I've used web developer toolbar for a long time, but it doesn't

7553:

Apart from those few cases, the use of rowspan/colspan should not be considered as an accessibility problem. No up-to-date expert resource nor the WCAG 2.0 guidelines recommend to avoid using rowspan/colspan. Fairly recent versions of screen readers (JAWS 6 - march 2005, and most used softwares)

7233:

element is implemented in assistive technologies as "some additional information that will be used (e.g. spoken) when the user request it". Which means that it should be used in contexts where the user will expect that the content is an abbreviation. Otherwise he won't have any chance to ask the

5100:

I've copied my suggested wording below, without any strikes or underlining. The last bit is admittedly not strong enough, but for the reasons outlined in the previous paragraph I think the line needs to be drawn there in the short term. It's a reasonable compromise; if an RfC started today, with

4852:

read. Partially-sighted readers (and even old folks like myself whose vision is much less acute than it used to be) have a choice of screen magnification or having highlighted text read out to us. The problem with screen magnification is that I often find I've lost my place in the article when I

4570:

Not all visually impaired users can afford the USD 895 or GBP 659 for technology as advanced as JAWS (that is an accessibility issue in itself), but they can make use of text-to-speech converters such as the simple one built into the Opera browser or the addons available for Firefox. Simply put,

3143:

From the style guide: "By default, most screen readers do not indicate text attributes (bold, italic, underline), so struck-out text is read normally along with any other text." The three examples of bold, italic, and underline are all considered presentational in HTML 4. But as I understand it,

166:

user, I've probably just gotten used to it and I've never thought of the order as unusual. But you're right, it would make more sense to have the office name and dates read first. I kinda like the current configuration as a mini-timeline though ... the earliest event is spoken first and the most

10645:

The lang template is used by some screen readers to change the spoken language of the text. For example the text {{lang|it|ciao}} will cause screen readers with the relevant feature enabled to say the word "ciao" in Italian. I myself don't have the "language detection" feature enabled, but some

8356:

on the page. There is only a description of the potential for problems. I've showed you that there exist such problems, which disadvantage certain classes of user, and I've attempted to suggest ways to solve them. I'm much more interested in updating the guidance to make it more usable, than in

6686:

You can't always guarantee that non-ascii characters will print as they are displayed on screen, so it's always worth checking, so Gnevin actually has a point. I can confirm that printing from Firefox under Windows XP to a pdf file displays the hearts character just as it displays on my screen.

6166:

WFC, I won't answer that one before you show me a concrete need to use it. There are several ways to code an accessible table. But to much code and different uses of the code will confuse editors. In the end, editors will make more mistakes. That's why we need simple and consistent code to make

2867:

Someone noted that "Resolution" is a subsection under the section "Article structure" allowing for a loophole, where no other pages need to be readable for special-needs viewers. Is that 3rd-level header a mistake, or should resolution not matter when reading other pages: project pages, essays,

1181:

in a discussion about show/hide collapsible content in another article. While the circumstances of that conversation were very different (show/hide was being used in image descriptions to hide spoiler content), the point about the JAWS 5.1 screen reader having no problems accessing collapsible

8495:

This one is a good use of the imagemap extension. It is accessible. We should make detailed guidelines about it. Like a tutorial on how to make accessible imagemaps. But it need to be in aother page than the MOS. If I understand correctly, MOS re editorial guidelines. But lots of accessibility

5092:

I agree with the idea of opening this to an centralised RfC, although my opinion is that we should wait until the help section has been created and is live, and until an FAQ has been devised (ideally by someone who understands the issues better than me) If we do it before we have all the bases

840:

here, and click the arrow next to the "Anchors in section headers " item in one of the entries. It should bring you straight to this section (or as close as possible, since this is on the bottom of the page), but instead it jsut brings you to the top of the page, because the internal anchor is

10378:

To my knowledge, there are now at least 6 templates of this nature (the daggers and card suits), and consensus is that there should eventually be a few more. Given this, perhaps we could list them on the access page, or at least provide a way of finding them? At the moment we have "Do not use

9062:

2000 for a decade, I can easily recognize that this image is of a relatively simple Excel spreadsheet, using basic Excel color choices. Although the pointers to different songs or albums appear to indicate very specific points in time, they in fact seem to be just to whole years in the column

7056:

Image links are placed on their own line with JAWS and other screen readers. So the output of the template sounds like this, where a comma is a line break: "k, of hearts", "2, of diamonds", etc. That's OK and far more readable than before, but I still prefer the solution that I implemented at

4532:

I know we will find tables that are nearly impossible to make accessible. Or at least, impossible without removing a sortable function or special layout that users appreciate. I found several on the french Knowledge already. The thing is users want to produce way more complex tables that what

7664:

You may well be mistaken; and F49 should not be taken as the last word on the issue. Table linearisation is just as much a concern for data tables as it is for layout tables, for exactly the same reasons. Since data tables are essentially no more than an organisational structure for the data

7565:

Plus, the community will never agree to let got of rowspan/colspan because they are so useful for presentation. We will encourage to make simple tables (and avoiding rowspan/colspan when relevant will be a part of that). But it should not be an accessibility requirement. Because it is not an

6097:

I will start out by saying that I'm out of my element here, and only discovered some of the discussed changes above by accident. I edit articles on highways, specifically highways in the US state of Michigan. Highway articles use a table to represent the major junctions along the highway. In

1489:(family trees, which use their own standardized family of collapsible Knowledge templates) don't appear in any form, even by title. Although I could chance some utterly-uninformed speculative guesses, I really have no notion why the two collapses should render differently in Print Preview on 10727:

Sure. I just hope my little explanation will suffice, please let me know if it is not the case. When I mentioned "complicated debates on how to use this template", It was in reply to Graham87's comment. I know it isn't what you asked for. :-) Please let us know if you feel the need for more

12498:

I think there will always be a tension between trying to make articles as accessible as possible and keeping advice simple. As you've said in the past, we should aim for what is achievable, not demand perfection – and I still agree. I don't want to see Lil'unique discouraged from improving

11260:

could (and should) be used in navboxes, in order to produce semantic lists. It has any number of other uses. It would be worth the effort, but might not be top priority as Graham87 said. Yet another tedious task that is gathering dust on my to-do list. Let's just say this template has some

8284:

which serves the same end. Since RNIB specifically names Lynx as a text browser that it uses for testing (WAC See It Right Standards, p.8), pages which fail on Lynx fail RNIB audit. I've already demonstrated that rowspans are not distinguished from empty cells in Lynx, resulting in loss of

8046:

Your approach is seriously lacking "prioritization" and "feasibility evaluation". WCAG 2.0 do not aim at 100% accessibility. Because it's plainly impossible. Instead, it encourages the most feasible and top-priority criterions to reach a good enough level of accessibility in a fairly short

5729:

As an example, consider a long, old-fashioned magazine article: It's a densely printed oblong gray blur. If you don't break it up visually, readers get fatigued and quit reading. Consequently, an editor might add dingbats, pull quotes, drop caps, bold text, small caps, italics, or other

8757:

You know, if I hadn't to spend most of my time discussing with you I would have finished my tutorial a long ago. Conclusion: I'll stop wasting my time in endless debates. If you continue to provide your own confused advices here and there I'll just answer "citation needed". Simple enough.

5161:

Having spent a couple of days looking over the issue, I think I've considerably underestimated the scale of the challenge; providing answers to most table-related problems is far beyond my level of access-related knowledge. I do maintain that the wording in the blockquote tag is closer to

4909:

We should advice to make simple tables in general whenever possible. And provide examples of ways to simplify a complex table, or to split it in small tables. We should also advice to avoid using rowspan/colspan when possible (without making it a detrimental requirement). And provide good

10952:

I think it's excellent, although the choice of "linen" as a colour is a little odd, it's quite hard to perceive. In any case, it's way, way better than the timeline template. It would be awesome if you could conjure up a generic timeline template (although I realise that's a big ask).

11582:

This is still not addressing the problem of the vertical bar and it looking non-vertical in some-cases, causing accessibility problems for some sighted people. This needs to be addressed before this template is widely used and it should not be recommended until this flaw in it is fixed.

8708:

lots of other priorities than making endless debates, testing supports in users agents and all. Experts already do all the job for us. We just need to make a decent manual of style out of the current extremely lacking draft we have. Why not go for the endless debates afterwards. Yours,

8655:

It is now very clear that WCAG 2.0 doesn't address redundant text for imagemaps because there is no need for it anymore. Major user agents support it. Other just have to keep up with them: they are not to hold the web back like IE6 does (that's an extreme example but you understand the

8198:

I suggested that F49 was "not the last word" on table linearisation, and provided an example. Let me be clearer then, the problem I have with your reliance on F49 is that F49 does not address data tables at all. The fact that F49 (Failure of Success Criterion 1.3.2 due to using an HTML

5885:

When a guideline needs a serious re-write, but at least parts of the structure can be retained, I've had some success with dealing with one issue at a time, on the talk page. Typically, you pick one section or paragraph, and propose changes just to that one part. That way, nobody's

1906:? Although it's not ideal, I believe that at 800x600 the current format is acceptable; three vertical images is not unreasonable given the relative length of the table. What I'm less sure about is whether that would remain the case were I to continue adding images. Thanks in advance, 9206:

with wikitables, but I'm not terribly familiar with the syntax on here, so Excel seemed more appealing. I can find a way to upload the xlsx file so others can have a hand at improving it. I don't come on here frequently enough to really support making changes. Hooray, open-source!

980:

but did not have an anchor and did not show up in the table of contents. This would be a good way to handle the pseudo heading used for introducing template documentation on a template page, and I can think of several other uses, where it would be sematically valuable to have actual

10629:

using the template. I guess that it helps screen readers to understand what language they're hearing (do they get a "French" or something spoken here?). Right now, for regular readers, there's no discernible gain to use the template, so some clarification would be useful to all.

5583:

in W3C's spec. Please check the source code produced by MediaWiki. What is a "definition term" (DD) without a "definition description" (DT)? Definitions are mostly for Wikitionary (and extremely useful there). The only article I found where use of DD and DT would be appropriate is

1985:

I think the outcome will either be to make the common style be mandatory (most likely) or the absence of a standard. As far as anyone here knows, does it make any difference in terms of accessibility? I assumed that it doesn't... but I'd rather not be relying on my assumptions.

419:, apparently with no discussion, and based on the revision summary is based on the misconception that placing links is no longer a problem. Keep in mind that section titles also act as anchors, which makes adding wikitext markup to them very problematic. The actual paragraph in 8207:: "1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined", which applies to all content, including data tables. You can also refer to the definition of "linearized table" in 7545:

There are a few precise cases where rowspan/colspan causes accessibility problems. Among other precise cases where a table has accessibility issues. I had already identified this cases before I asked the expert and he confirmed my thoughts. I will make a list of those cases on

114:

On many Knowledge pages, temporal sequences are generated as HTML tables with "preceded by" and "succeeded by" cells in each row. For instance, is preceded by person x and followed by person y for several different public offices. These are stated in the following sequence:

7025:

Re using User:Chzz/cardtest. I'm responding to the note dropped on the gambling page. I'd vote strongly against the change to this proposed template. The images are totally blurry. I wonder why there is even a question with them being blurry. They are simply not useable!

4913:

I believe you both are capable of making examples and tutorials for that. I personally won't have time to do everything. There is so much to be done in this guideline. And so much to do with developers and the Wikimedia Foundation. Could you do it? That would be a great help.

5771:, I've never made skins or monobooks or CSS one of my preferences. In that I'm sure I'm with quite a large majority of registered editors. And registered editors are only a very small fraction of all Knowledge editors and thus a minute sliver of Knowledge readers. So saying " 7403:

I have explained how they interfere with access: A person who cannot scroll to the end of a list because using a mouse causes him (or her) physical pain is prevented from reading the hidden text. Perhaps you could explain how hiding text supposedly makes it more visible?

12499:

accessibility in articles, but I don't want unnecessary conflict either. I suspect that time is on our side: a wiki improves incrementally, and all we need to do is nurture good practice and encourage good editors. As we might say about a wiki, "Plus ça change, plus c'est

6899:

contains a list of different codes to produce a heart. The one used now is a unicode character. But HTML codes can also be used to produce those signs and may have a better result in screen readers. How does screen readers read 1) ♥ 2) ♥ or 3) ♥ ? Is there a difference ?

10992:

I made some minor changes to the bar color, use em units, and split the rows into table rows, which may parse better on a text only browser. Hopefully this doesn't break anything. I believe we could turn this into a more general horizontal bar graph template. Thanks!

8168:

only one who is backing up his assertions with references. I was one of the first users to insert references from WCAG 2.0 in this guideline. Most of the current references were inserted by me. And I'm the only one who is trying to provide references during discussions.

6106:, any time there are multiple junctions in the same county, the county name cell spans the rows. The same goes for the municipal locations like cities, townships, villages, etc. Is there a table formatting parameter I should add to the templates to update these tables? 7566:

accessibility requirement. We should not create our own guidelines or else we'll just end up doing a poor job (like what happened with alt texts a few months ago). Our role is only to meet the WCAG 2.0 conformance. Perfection is the enemy of good enough. Kind regards,

9155:

accessibility needs for readers on low-bandwidth connections, then image maps don't do well, particularly on text-only browsers such as Lynx. Overall, a well-implemented table will always be the solution that goes furthest to meeting present accessibility concerns. --

5127:

is currently under review. Colspans and rowspans should be used sparingly; they should not be used in an overly confusing or purely decorative manner. Rowspans in particular can cause accessibility issues; an example of the output from a screen reader is demonstrated

4605:

Note that most blind users won't use Opera voice and Firefox Add-ons. The reason for it is simple: it only works inside the browser. Which means they need a screen reader to use the desktop and launch the browser. If they dont have money, they may use the open-source

5753:.css stylesheet – which is the place to do it. Hard-coding formatting merely imposes one presentation style on all sighted readers. If an article actually requires something to break up the text visually, isn't that usually a sign that some rewriting is in order? -- 11567:

Although I concede that it really needs another parameter to turn off that CSS border between the elements. I'd probably use an image of a mid-dot with null alt text and no link as a separator if I were re-designing it, or do it in css by using a supported bullet.

12397:

which gives results of testing that sort of markup for HPR 3.02, Window-Eyes 4.5, JAWS 4.51, JAWS 7.1, and JAWS 8. It worth study because it shows quite clearly for example that Window-Eyes up to version 6 does not recognise the 'scope=row' set on cells in column

5726:

of them. So if you're putting a sentence in bold-faced text as signal that (1) is needed for some sighted people and (2) is never needed for non-sighted people, then why should this signal be arranged to be "visible" to non-sighted people, for whom it is useless?

4958:

take that long, but I'm involved in two FLCs and a GAN right now, and am on holiday towards the end of the month). The first half of September to draft it in my userspace, plus time to get feedback and make modifications before moving it into the Help namespace.

4469:

I have a hard time to understand the warnings about colspan/rowspan either. But I believe it intends to teach about common pitfalls rather than prohibiting its use. If we can find the author of theses paragraphs we could ask him/her to provide practical examples.

7581:

Thanks. It's tricky because while colspan and rowspan can be used to make elegant but over-elaborate tables with lots of hierarchy, they're often used for the opposite purpose: to simplify tables, i.e. to present information in the easiest, most transparent way.

2021:

I've removed the nowiki tags, because the appearance might matter to someone with less severe visual impairments, or with text processing problems like dyslexia. The difference might be unimportant to users of screen readers, and important to some other user.

12518:

collection of GA articles and two years + experience to see to emulate the editing decisions i make when it comes to style. I wish the people over at American Idol would see that their entire project is a deviation from projects like The X Factor (especially

11988:

but was gunned down in an instance. I brought it up on the talk page, and was again steam rolled. The opposition appears to be that the Idol project has their own standards of doing things. In particular i'm concerned with tables which use formatting such as

10915:

Oh, and I agree with Graham87 of course: your graph has potential to become perfectly accessible, trough the techniques Graham87 suggested. If you're unsure about the methods to further improve accessibility, I'll be glad to help you with the coding. Cheers,

8027:

As I said before, there's no need to "hang out to dry" readers who depend on text-to-speech and text-only-browsers while they wait for technology to improve. Better, simpler design and some consideration of the impact on others is still key. Hope that helps.

4743:

and some others are working to improve markup on the 'pedia, and I believe good markup goes hand-in-hand with good accessibility, so there may be a few more editors interested in such a venture. I'd be more than happy to help out in whatever small way I can.

4643:

who is registered blind and has a guide dog, but he has one-sixth vision and can design web pages. With the assistance of text-to-speech, he is able to ensure that what he thinks he is reading actually corresponds to the text. He – and many others like him –

10822:

Regardless, as The Rambling Man pointed out, this information is irrelevant in this accessibility MOS. This page explains what editors must do to produce accessible articles. Techniques and advices for the screen reader users should be moved to other pages.

8121:

needs to be split into two pages- a policy, for things which should be considered non-negotiable, and a non-MoS guideline, for things that we should always try to do, but in some instances simply aren't feasible with the current limitations of the software.

5866:

or a subpage of this talk page here. I guess it would depend on the principal audience you are looking to draw into discussion. Either way, it would be appropriate to post a brief notice on each of the talk pages, drawing attention to your proposals. Cheers

4721:@RexxS: yes, I know about that and we agree. My reply was too short and misleading, sorry about that. This note was only intended to avoid a common pitfall when evaluating accessibility. I think a FAQ would be more efficient to teach about common pitfalls. 12248:. It must be that feeling of anonymity on the internet. I hope that if he personally knew a blind person, he would not be so determined to prevent his own friends and acquaintances to read the article. It costs us so little to fix some of these problems. 12112:

Yep. You would need to show me something that mandates a requirement to meet WCAG accessiibility. In five-and-a-half years, I've seen nothing close to that. These are "style" guidelines as far as Knowledge's MOS is concerned. Optional in almost cases.

9605:

links team names every line. This is, obviously, because the table is sortable and therefore the data could be presented in any order, so there's no guarantee that linking just the first occurrence is adequate as it may not appear first after a re--sort.

8042:

I know you act on good faith. And it's nice to see you are quite knowledgeable about accessibility. But don't you dare think you know better than one of the best french accessibility expert (Lgd). Plus Lgd has about 5 years of experience on the Wikimedia

6748:

is available from the extended editor interface, so is quicker to use for editors (in my case it's just laziness). In fact, since almost the only use on-Wiki is to indicate deleted content in talk, we ought to be asking for it to be replaced by <del:

12176:

There are actually very few requirements on Knowledge. They include: Do not violate copyrights, do not vandalize, and do not make threats. For these—if the community notices, at least—you'll get blocked. Beyond that, it's largely good advice, not

10159:

Sure. :-) I don't have the time to update this page anytime soon. And much less to participate in the drastic work that comes with it. Though we will need to work on infoboxes one day, I'm perfectly fine with removing this section for now - solution

6402:, but I'm not sure yet. Using icons with alt text (red Ace hearts) is a rock solid solution to this. But before suggesting this change, I would like to learn more about the hearts and their result in screen readers. I'll ask an accessibility expert. 10163:

Note: I had some free time this week-end, so I decided to see how things are going and make a few edits. A lot of important discussions just begun, so I'll do my best to keep an eye on it, but I can't guarantee I'll be able to participate. Regards,

7459:, and tell me how any reader with severe RSI could possibly decide (before clicking on anything, and without assuming magical knowledge) whether or not the pain involved in clicking on the button under "Personality traits" is likely to be worth it. 3222:

Sorry, I misinterpreted your question. The answer is the same with semantic text attributes; they're not indicated by default either. Additionally, there's no way to distinguish them from normal text attributes: I can't tell the difference between

2433:

Perhaps; but the very idea of granting FA status to an article with images which require, but do not have, alt text on images with meaningful/ textual content - and thus whose content is unavailable to some of our users - is absurd. And offensive.

7489:. I understand the problem with over-dependence on mousing, especially right-clicking, but sometimes the alternative would be repetitively hitting keys rather than mice. However, I think that keyboard shortcuts are definitely worth investigating. 4997:

a ready-made list of solutions strikes me as going too far too fast. I see this as the appropriate middle ground, subject to adhering to the timescale I've outlined above and reviewing this towards the end of September. Does that sound workable?

1703:

Print preview isn't a good test in this case. There is no reason to print a navbox since it would be useless on paper, so I think they were deliberately disabled in printing. I think a better test would be to find out if the end navboxes work on

10363:

I'll do the same, and make recommendations to editors nominating cricket lists where use of the dagger is commonplace. I'll also note it wherever I see it in other nominations which just happen to use the dagger to identify something. Cheers.

1617:

I've finally opened Firefox 3.6 and the Print Preview opens out those games in the middle of Watford's 2009-10 season. However, the Print Preview doesn't show the collapsible navigation boxes at the bottom of the page, for either Watford or for

10877:. The top bar chart is the new one that I just made, and the bottom is one using the "timeline" syntax. It seems to me that the top one should be better for a variety of reasons, but I only have one browser, so I thought I would check here. 9402: 9363: 8050:

Your approach will never be adopted by editors because it's way too difficult to conform to. We have experience on the excessive burden that accessibility can cause on editors. So please trust us. And please don't repeat the same mistake that

9679:

criteria in any accessibility methodology. And the problems that overlinking causes to blind users are on pair with the problems overlinking causes on "normal" users. Overlinking is reather a usability issue that would be worth mentioning at

8699:

I never said users should change their preferred browser. I said user agents that doesn't have keyboard support for imagemaps should be improved. And that is all. I'm well aware of browsers usages and I've just spend several hours improving

6158:

improves accessibility, and is a good first step. The guidelines for further improvements (including rowspan/colspan) are currently debated and are not yet written. It is too early to make further improvements. Please check the evolution of

3437:

errors in their purest sense (i.e. excluding spelling, punctuation, and capitalisation) do not affect the sound of the text with a speech synthesizer. Regarding spelling, in my experience, most blind people, especially those who do not read

8292:, and although little of it breaks accessibility, much of it will be poorly presented for those using AT, low-bandwidth connections or low-resolution screens. As an example, take the "Global usage share data" table. The use of <br /: --> 5213:

is "available", but doesn't mandate it. Unicode characters for ½, ⅓, etc. appear in the Symbols tab of the insertion bar below our edit window, so presumably they are endorsed somewhat. However, many popular browsers render the output of

7710:

attributes is definitely not an accessibility issue. If you want to improve Knowledge's accessibility, please stick to Web accessibility standards and don't add extra requirements to WCAG2.0 : WCAG AA level is difficult enough to achieve

6053:

articles will reflect those changes before they are codified in MOS. If that becomes a barrier to FA/GA status, then it is an issue to take up with the FA delegates and GA reviewers, as they are the ones enforcing particular styles. When

5575:

on usability wiki) about it. He replied: "Why are you doing that? You'll just be reverted!". I answered that my previous experiences in guidelines improvement on en.wiki were quite successful. And I believe there are a lot of smart folks

4861:

what technologies are appropriate. It reminds me strongly of the old days when some websites carried a message "This website is best viewed in Internet Explorer at 800x600" because the developer was incapable of catering for diversity. --

2617:

Having the exact same name repeated in the article title, the first sentence of the article, the infobox title, and the photo caption seems like it might be repetitive and confusing if a device like a screen reader is used. Consider the

1254:

Can you elaborate on the problems collapisble content could cause with screen magnifires? I played around the one included in Windows7, "Magnifier", and it seemed to work just fine in all 3 modes (full screen, lens, and docked) with my

9869:

where a template creates the links to good effect, although I'd be cautious about having large numbers of links within a section header, because of the nuisance value to screen readers. I checked with a regular editor who uses JAWS and

8337:

No. It's the recommendation against rowspans / colspans that is debated. Until we reach consensus it shall be removed. In the meantime I placed on those paragraphs. If you still disagree on that, disagree elsewhere. I'm pissed off. :(

11008: 10874: 10647: 10265:, so I'd like to see us giving stronger guidance here to that effect. I can now make a template for any displayable symbol, but I'm still undecided on whether to use anti-aliased or non-aliased images for each symbol. Which is better: 6011:

because like I said there's no clear goal of exactly what is trying to be achieved. There's also too much 'expert' opinion being chucked around but not enough evidence or examples of the on-going changes / what needs to be changed. --

1375:

Knowledge content should be as easy to copy or reuse as possible, IMO; there are probably many offline mirrors for personal use, so they're not just for advertising. Mirrors and forks don't have much to do with accessibility, however.

10066: 5359:

The last denominator is an image (screen capture from IE8). The wikitable markup looks ok in FF3.6 and Opera 10.60. I can check other browsers if you wish, but I expect Internet Explorer will have a problem in any version (as usual).

12064:. A better approach, rather than crying "ownership", is to try to work with projects to help them see that many accessibility changes can be made relatively simply without compromising articles for the regular viewers. That's what 9831:

I believe this is no longer an accessibility issue, and should be removed. Originally there was a software problem in making anchors containing links, but the developers resolved that some time ago, and there is now this guidance at

5685: 5030:

points into account. As I say, this is only an interim measure, to reflect the fact that there is no consensus for the previous version, but consensus that colspans, rowspans (and images) need to be given consideration. Thoughts? --

7237:

In the case of Unicode emoticons, it's much more robust to use an icon with alt text. That way we are sure the information is conveyed properly to screen reader users. In the case of ASCII art, both abbreviations and images can be

1300:

Ah, I'm sorry. I misunderstood your comment when I read it the first time. That makes sense now. Thanks for the clarification and I appreciate your input on this especially as someone who can speak from experience. Thank you!

9248:

I personally didn't think they were important enough to the point I wanted to make with the graph. I was interested in who the full members of the band were for the different albums, and thought others would like to see it too.

6184: 2887:

I think it was an oversight. IMO all pages on Knowledge should be usable on 800x600 resolutions. I can't think of many cases where this rule is a problem, except perhaps large data tables for WikiProjects or statistics tables.

2653:

has been removing the "thumb" attribute from line art images in articles, pointing to a general "disclaimer" on the WP:AIR MoS which says that users are not "obliged" to follow the image use guidelines. Comments are welcome at

1497:

D1341 printer). I could do a test print, but I don't really want to unless really necessary. If anyone wants sample screenshots of my print previews and has some very easy way of transmitting and receiving them (e.g. e-mailing

452:

To expand on that: anchors use HTML ids which must follow rules. The only allowable characters are alphabetic, numeric and hyphens, underscores, colons and periods. Thus the brackets used in wikilinks will render invalid HTML.

8357:

removing useful commentary. I have no interest in reducing the page to a cut-down summary of WCAG 2.0. That is already adequately referenced in the page and viewers should be encouraged to read it. And the way we work here is

2368: 6306:"If a completely new editor wishes to modify the article with credible information they will find it extremely difficult because they won't know all of the intricate coding that goes into making the page look pretty." -: --> 3826:

other sort operations, it will be sorted alphabetically, unless something is done to prevent this. Some of the methods involve a hidden row containing the proper data types, and all involve some variety of CSS markup. See

6006:

Us lot at discogs have been thrown into the deep end because someone decided to criticise the entire project. This has resulted in the stalling of an FL nomination and an indescriminate messy discussion at the talk page of

9748:), and I'd appreciate any thoughts on how we should be presenting guidance on alternative methods of providing information conveyed by colour. Specifically, I think the guidance on using italic text needs to be removed. -- 12346:

and ask for explanations. I hope I'm not being too sharp here, because I really appreciate your participation. However, this is an important issue in our accessibility team. I hope we can fix this issue and move forward.

10701:

I'll be able to start advocating its use at FLC because our contributors will understand the benefit of just a few extra characters that don't get in the way of 99.99% of our readership! Win–win I think they call it...!

3479: 12086:

Are you saying there's no mandate for Knowledge to meet WCAG accessibility guidelines? I know you can't prove a negative, but can you show anything to back that up (I'm not being argumentative; I'm geninely interested).

8365:. I'd strongly recommend you read those two pages, as you may not be familiar with their concepts. I'm ready to discuss calmly what you want to change, whenever you're willing to do so without threatening to edit war. -- 4879:

might be appropriate. Explicitly requiring alt text for any images in a table I fully agree with. Indeed, I also agree that we should depricate images unless clearly appropriate (for example the key, images and alt text

8186:

That sounds like a good way forward, Dodoïste, and I'm keep to help any way I can. We're not going to agree on every point, but I respect your commitment and enthusiasm. Did you notice the reference I provided from the

7633:

This is a fine example. It can be used to encourage users to make simple tables. But as I said previously it should not be an accessibility requirement. If you want to have a detailed answer you can ask him yourself at

1000:

doesn't seem to ignore its later parameters and the sky doesn't fall down. I have no idea how long it would take to convince the developers to do something like this. I haven't been in the WP Bugzilla for a long time.

9385:

to the image. Is this sufficient or do I need to change the map itself? As for "1.", I have no idea how to make it more accessible. I am therefore looking for some help from an accessibility export. Thanks in advance.

8833:

Many viewers turn off images because they don't live in a country where cheap, high-bandwidth connections are available. That's most of the world. If we are aware of a problem/bug that exists in Firefox or Lynx or IE6

5592:

Almost correct. But most uses of 'b' and 'i' are for layout only, which is why they were deprecated. 'Strong' and 'em' are semantical emphasis, not typographical layout. In short, MediaWiki is correct in his behavior.

2397: 1812:

quicklinks should be moved to the "Scrolling lists" section of the main MOS article and the title of that section should be updated to be "Scrolling and collapsible content". On his talk page, Happy-melon has already

1869:

Okay, I made the updates and followed WFCforLife's suggestion of porting that segment over. I also tried to clean up the text a bit. Let me know if any of the additional changes are concerning. Here are the diffs:

1743:

and made changes that reflect the spirit of WP:ACCESS, while trying to get across my complaint with it. Hopefully it will stick, but at least if it's contested we should get an explanation of why it is the way it is.

12360: 6606:

On the contrary, that's exactly what an abbr tag is for. Semantically, the two characters 'A♥' (the output of the template) is an abbreviation for "Ace of Hearts", just as 'WHO' is an abbreviation for "World Health

10103:

and clear, unambiguous instruction is the only way forward. I appreciate the ongoing efforts to make it more accurate, more relevant, and I also appreciate my (possibly naive) comments being given consideration.

9780:

Without extra information to alert a screen reader, I think italic text is a poor choice for providing an alternative to colour, so I've amended the guidance to recommend an accessible symbol with matching legend.

6264: 2128:

I don't understand the problem, as no examples are given it appears that Kudpung is offended by the use of American English instead British English and the only solution is to change everything to British English.

8659:

Accessibility-wise there is no need to encourage redundant links anymore. Now usability-wise it's another story. Most imagemaps are not intuitive at all. Depending on the situations redundant links could improve

7272:

element is part of their recommended solution. However, here we are not dealing with ascii-art, unicode emoticons, nor leet-speak. As you're no doubt aware, H86 notes that not all assistive technology deals with

6242: 3342:

Something like "The position of foreign language templates does not matter for accessibility"? But it feels clunky to put it in the heading about the lead section, especially when that part of the page defers to

9264:

xls nor xlsx are supported filetypes in wikimedia commons... If you point me to a tool to convert the excel spreadsheets to a wiki table or any of the other things mentioned, I'll take a look at converting it.

6311:

Interoperability is one of the induced effects of accessibility (and a part of the "universal accessibility" approach) but is not the main goal in itself. Though it's often strongly encouraged by accessibility

1791:

At this point I think there has been enough evidence presented to conclude that there are no accessibility concerns with this type of content. Therefore, I propose that this section be removed completely from

11297:

Well... Without changing its appearance, the table of contents and the navbox couls use such a flatlist. There would only be a semantic difference, without any change in appearance. It's only unfortunate that

7462:

Rather than a shortcut or user style to expand text, I'd suggest that this approach NOT be used to hide text. I think it reasonable to assume that readers will generally prefer more information by default.

5228:

confirms problems still exist. (The template was nominated for deletion for some of these reasons just a few weeks ago.) My question is which of the following is preferred from an accessibility perspective:

12471:

Is it really such a high priority? The most important thing is for the column headers to be marked with scope=col. If there is no consensus for this edit, it's okay, don't push too hard. We're not in a rush

10912:

Indeed, your new bar chart surely improves accessibility. Nice one! :-) Also, don't worry about the rendering in different browsers: there is nothing in the graph code that may cause any issue with browsers.

9320: 9285: 8592:

WCAG 1.0 is outdated as you already know. If you know of a corresponding criterion in WCAG 2.0 we will follow it. If there is no corresponding criterion in WCAG 2.0 I would advice not to follow the WCAG 1.0

12430:

necessary in HTML4, although for a header at least one is; but we already know that SCOPE won't be allowed on TD in HTML5 – and frankly it's clearer to advise TH SCOPE because it's never wrong to have both.

12172:

Complying with the MoS is recommended but not required for any article. FA has freely chosen not to award FA status to any article that doesn't comply with the MoS, but there's no requirement to attain FA

5810:

if you have the new skin) for you to have bigger, bold, level 2 headings. The point I'm trying to make is that we can make reading easier for those who want the help, but we won't do it by inserting <b:

971:

variant that does something special, usually prevention of some expected effect (suppression of inlining an image, suppression of putting a page in a category, etc.), in this case it could perhaps be that

12318: 11650:

list-header tag existed, then I'd have marked up the country with it. Just because you can't see the semantic connection between a country and the cities in it, there's no need to insult those who can. --

8097:

100% accessibility. If you are satisfied with less, that's your choice, but please don't obstruct those who want to aim higher. We know improvements don't happen overnight, but they do happen eventually.

1237:

Collapsed sections aren't an accessibility issue AFAIK. I've never had any problems with scrolling referenced lists, but I can understand how they could cause problems for people using screen magnifiers.

10333:

to use the plain (non-anti-aliased) images. It may take a while before the cached image is replaced by the new one. I'll bear the anti-aliasing in mind when we need to create other accessible symbols. --

9945:

These are back again for reflists, despite ".references-small { font-size: 100%; }". And since most readers of WP don't have accounts, even if botching the CSS was a good solution, it is only for a few.

7558:). W3C's guidelines have to ensure the conformed content can be used be assistive technologies. And it's the responsibility of the user agent providers to make sure they produce accessible technologies ( 3416: 12548:

feel it doesn't help please state it clearly so that my little brain can understand. ;-) I'm able to hear criticisms about my behavior, and I even like it since it enables me to improve myself. Cheers,

3468: 2906:

Thanks for clarifying that. I hoped it was approved for all pages, so using Text-size "Larger" (or Firefox "Zoom-in") would still render balanced pages. I have convinced editors to re-typeset guideline

1221:

On a slight tangent, the last sentence of this guideline suggests that we should only ever collapse a navbox where all the content is already linked to in the article body. Am I misunderstanding this?

4822:

I found several old accessibility tutorials and guidelines saying we should avoid rowspan/colspan. And they seem to be outdated. For example, WebAIM's article that recommends to avoid rowspan/colspan

899:, etc.) as long as the original name is also one of the anchors. It is still messy, though, and there has to be a better way. I propose one below, that would require MediaWiki developer attention. — 2001:

It doesn't make a bit of difference in terms of accessibility, since all modern screen readers recognise the non-breaking space character. I've gone ahead and put nowiki tags around your examples.

790:

PS. Hmm, for the previous example to work in my browser, it appears that there needs to be a lot of text in the window, or for there to be a very small window. You might need to follow the link to

2872:

There has been quite a battle to ensure disambiguation pages are not considered to be article pages (so they won't contain any extensive text, and don't need to follow any rules about articles). -

8453:

is right to be high-level and summarize the guideline. Thumbnails are the most common cases in articles. But in data tables images a generally decorative images. The relevant informations are in

5420:. Those best practices are written by an accessibility expert. I also saw this practice on the English Knowledge here and there, so I assumed there wouldn't be any problem with it. Any thoughts? 4888:). As for rowspan and colspan, I'd say add some sort of wording suggesting that colspan and rowspan are allowed, but that there should be a demonstrable benefit. As I see it, our opinions aren't 7542:

Hi all. Several days ago I got the answer from an accessibility expert about this issue. The whole answer is quite long, and I'll need some time to translate it completely. Here is the summary:

5538:

I did not see that the ";" were recently added to Kelly Rowland discography. I provided a link to this MOS only to add explanations the edit summary couldn't contain. I just edited this article

8382:

Sight. Just relax for a few days and stop posting here. I'll make this tutorial quietly. We'll resume this discussion afterwards. That's the only solution since we don't understand each other.

7532: 6297: 5535:

Oh my. A few explanations, but very short as I would really hate to get in a personal dispute or something. I don't want to hurt anyone, and I apologize if my edits were perceived in that way.

4438:

constitutes a massive change to the MoS, and should probably be subject to wider scrutiny. If I have misinterpreted, perhaps some clarification would be in order on these concerns? Regards, --

10144:

Either (a) the MOS needs to stop referring to a page which introduces itself as inactive and outdated or (b) the page it links to is made active and updated, and the initial caveat removed.

6303:

Good idea indeed. Whoa, there are far too many things going on here, I can't keep up. I won't be able to comment in detail before this w-e, please remind me my duty. ;-) For now, the basics:

11912: 10046:

Spelling errors, such as "initative" instead of "initiative", can dramatically affect the sound of the text when it is read by a speech synthesizer, which can make it more difficult to read.

7575: 4554:

For what it's worth, I have never encountered any problems with the use of colspan/rowspan. The major problem I've had with tables over the years is improper/missing row and column headers.

1411:

within the main article for Victoria, Albert and the spouses of each of their children to allow an interested reader to reconstruct ancestry back for several generations (for example Kaiser

10495:

Quickly - no :( I've just spent an hour trying to make a spade symbol that looks good even when the screen is zoomed. And of course, I can't. Here's the text symbol followed by the image: ♠

4529:

I have yet to see an appropriate use of rowspan/colspan that would be incompatible with accessibility. Could you provide examples of complex tables or sortable tables using rowspan/colspan?

12481:, using a scope=row in every row, but the header marked is in the second column. While standard and perfectly accessible, this will confuse editors. I think it's better if we can avoid it. 12372: 5443:

a bit of a change I had made to an article. Thing is, those two "headers" you added were setting-off trivial amount of content. And I was not using the three-apostrophe syntax to indicate

10498: 9521:, so why does the image use a transparent background? Either way, whether you do or don't know what the page color will be, it doesn't make sense to use transparent backgrounds in images. 7554:

support rowspan/colspan. It's the responsibility of text-to-speech and Opera Voice producers to update their software. Our part of the job is to make sure we conform to W3C's guidelines (

10379:

unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead." But as far as I can tell, there is no further help for an editor wishing to follow this guidance. —

11991:{| border="5" cellpadding="3" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 90%;" |- bgcolor="#CCCCCC" 11364: 9725:"... By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) or even semantic text attributes (emphasis, importance, text deletion) ..." 9585:

Can you give me an example? I've never had any trouble with overlinking in sortable data tables. When I wrote that sentence, I basically meant "Here's one more reason not to overlink".

3845:

The table sort function used on Knowledge is very lacking (and especially unsuitable for complex tables). We should ask developers to improve it rather than making fragile workarounds.

3822:

It's a trick to make tables sort properly. For example, if the column you'd like to sort by happens to have a non-numeric entry at the top of the data (such as a footnote or "—"), even

10254: 8685:

for an example of browser usage). When all common user agents provide links for image maps, then WCAG 2.0 will be adequate. Until then, old-fashioned redundancy is still necessary. --

7512: 6061:, then it will be reasonable for reviewers to ask for compliance, but if the recommendations at DISCOG were to conflict with the MOS, then it is clear that MOS will override them per 5548:

I'm happy that this guideline is part of the MOS. But don't you ever forget that it was written by enthusiastic amateurs. This page is really lacking. Hopefully it's better than what

2980:

I feel that prohibition of color-on-color text is ludicrous. It's, as Twain had said about censorship, "like telling a grown man he can't have a steak because a baby can't chew it."

2242: 1579:

9 on my Windows Vista computer (for an HP DeskJet D1341 printer): that is, the collapsed pictures open out and display, while there is no indication (other than a blank line) for the

11231: 9081:

Converting into a table is a very good idea (both accessibility-wise and bandwidth-wise). And it is feasible, although it may be a bit tricky. I'll provide an example soon. Regards,

5526:

please go slower with this stuff. There are at present only a few folks aware of these discussions, and this is a really big project with a lot of people with a lot of strong views.

4649:

the same software as those fortunate enough to be fully sighted. That takes it well beyond the realms of "pure curiosity" as far as Knowledge (or any other web content) is concerned.

405: 11160: 6914:

A quick way to estimate any difference is to examine how a browser renders the html delivered to it (and that will depend on the coding set for the page, "charset=UTF-8" for Wiki):

5417: 3136: 127:

While these tables are to be read in sequence, and therefore probably don't constitute a navigation issue for not having column headings, the sequence when read aloud is likely odd

12122: 12107: 12081: 9740:

The context in which I'm considering this is when a table uses colour as a key in a legend, and the editor has chosen to employ italic text as the accessible alternative (see e.g.

8293:

inside the cells to attempt to force a visual effect is wholly inappropriate and a nuisance for anyone using a screen reader. The explicit repetition of the header at the end is a

7306:. F26 is about "pictorial or decorative character symbol (glyph) which imparts information nonverbally" and suggest to use "an image with a text alternative instead of the glyph". 4526:

Let's review this rowspan/colspan case in detail before making decisions. One thing is sure though: the warnings about rowspan/colspan are misleading, vague and possibly incorrect.

2100: 156: 10962: 10551:"Note also that the image should be inside the section it belongs to (after the header and after any links to other articles), and not just before the header for similar reasons." 7537: 6277: 5320: 2881: 2363: 10678:. I don't feel the need to get into complicated debates on how to use this template (unlike some passionated users). Indicating language changes should be quite straightforward. 8085:

necessary, and often have a negative impact on the accessibility of the data, as I have demonstrated. Advising editors to consider these implications is the very least we can do.

2321: 1344:

to reproduce them myself if possible to understand them further. Likewise, can you point me at any Wiki mirrors that can illustrate problems with collapsible conent? Thanks! --

10408: 10390: 10373: 8077:

I flatly refute your assertion that giving good, simple guidance for editors is infeasible. We have an aim that text in our best articles be presented as "brilliant prose" (see

7736:

Table linearization only applies to layout tables, and never to data tables. Data tables linearization doesn't make any sense. That's why data tables must have header cells and

6270: 4652:

WFC, I have CLC FireVox addon installed and am quite happy with it. It may be worth trying out different ones until you find one you like (they are easy enough to uninstall). --

1708:. (Notice that I said "work", not "look good"). If they work, then they're is no accessibility problem with article navboxes. If they don't work, which is quite unlikely, then 12356: 12047: 11412: 11317: 11292: 11245: 11179: 10987: 10798: 10737: 10710: 10665: 10584: 10274: 10173: 10113: 9661: 9645: 9631: 9615: 9596: 5803: 5658:

I agree with most of what you said. The biggest problem here is the high difficulty to produce semantically correct content with definition list in MediaWiki. Just try to fix

2374: 2283: 1133:. Intrigued by the claims being made by this editor based on the advice found here, I set out to investigate exactly how "inaccessible" it is. I discovered the following... 353: 12193: 11346: 10042:

Spelling errors should be fixed anyway, and editors do make theses corrections spontaneously every day. I feel the following requirement is not needed, and could be removed.

7518: 7472: 7447: 6047: 6027: 6001: 5545:

By the way I'm a man, and I stated on my french userpage that I love women. There is one person editing in front of my screen – me – so please stop referring to me as "they".

5390:

be used, since screen readers will read it consistently. JAWS (and most other screen readers) are only able to read the fraction characters "½" and "¼" correctly by default.

5112: 5087: 5041: 5020: 4785: 2857: 296: 12156: 11958: 10432: 9602: 7498: 6128: 3210: 2989: 2257: 1162:

browser installed. It does not have a "Print Preview..." feature, but when I actually printed the page, I discovered that it too expands the boxscores in it's print output.

178: 11577: 10532: 10510: 10458: 10444: 10342: 10320: 10286: 9332: 9297: 5602: 5455: 4933: 4800: 3612:

However, you know much more than accessibility. If you prefer title in the first column, do you know a way to switch columns - I don't have the time do it one at a time. --

2739:. This case should be fairly easy since the text is the content and the graphic is mostly decoration, although provide a cue to the reader if there is a majority. Thanks! 2595: 1230: 640:

However, the text of a template will show up as an anchor if the template is used as a section header, per my sandbox. That could make it difficult to link to the section.

11617: 11444: 11071: 11047: 11023: 11002: 10947: 10758:. All it says is that shortcuts exist and can be disabled. Can we clarify what this has to do with web accessibility and why disabling them is relevant? Of course, the 10449:

That sounds like an excellent idea, and one that all (potential and actual) featured material (as a minimum) could use to ensure we've got brilliant accessible material.

9258: 9215: 8913: 8899: 8828: 8434:

recommends the use of image captions. Do we want to imply that captions should be used for images in tables? If not, it might be worth noting that as an exception. HTH. --

7413: 7381: 6149: 5913: 5807: 5743: 4848:

that anyone who reads tables linearly can encounter difficulties. My friend, for example, finds NVDA unusable because it overwhelms him with information, much of which he

3514: 3500: 3358: 3337: 2768: 2748: 2710: 2627: 2607: 2454: 2428: 2079: 2053: 2031: 2012: 1698: 1666: 1631: 1612: 1558: 1525: 1101: 1080: 516: 493: 12557: 9484: 9465: 7035: 6361: 6098:

Michigan, with a few exceptions, the tables are built using templates, so any necessary changes can be made to the templates to deploy the changes state-wide. I've added

5958: 5009: 4449: 3854: 3840: 3803: 3116: 3080: 3066: 2971: 2804:, shown above. It would need some modifications to move the text to a better place, and reduce the size a bit. However a simple text overlay is probably the best here. 1356: 1338: 1148:

browser (which does text only) on my machine and browsed to the page. I discovered that the full, expanded content of the boxscores (not just the first line) is visible.

921: 589: 557: 333: 309: 262: 11891: 11866: 11851: 11826: 11685: 11659: 11644: 10886: 10480:

Any chance we can quickly (?!) make those card symbols accessible too? They are used quite extensively throughout lists so an easy "find-an-replace" would be perfect.

10268: 9200: 9090: 9076: 8814: 7591: 6176: 5530: 5486: 5436: 5188: 5063: 4923: 4839: 4817: 4634: 4549: 4533:

MediaWiki is currently able to produce. In those cases, we should focus on improvements in MediaWiki, and not reduce the quality of tables for the sake of accessibility.

4518: 4479: 3870: 3302: 2233:

template. The previous language could be misread as if the American spelling was preferred. I changed it, but of course the language is more clumsy now for little gain.

1864: 1723: 1387: 1216: 12287: 12264: 12227: 11973: 10892:

Yes, the first version is much better. For better accessibility, add a table caption and row and column headers to it, so screen readers can detect it as a data table.

10781: 7438:

themselves from scrolling over it, under far less arduous circumstances. p.s. I wonder if anyone makes a large laptop-style touch pad for people to operate by foot...

6492: 5899: 5762: 5624:

Definition lists are actually semantically appropriate whenever you have a list consisting of pairs of items that are related; W3C gives examples of other uses such as

5469:

could usefully be expanded. It's also likely that this guideline would benefit from some guidance along the lines of Dodoïste's edit to emphasise the issues around the

5354: 5154: 3045: 1844: 1780: 1594: 1511: 1462: 1370: 831: 464: 369: 12542: 11270: 11125: 10925: 10903: 10856: 10687: 10602: 10197: 10094: 10080: 10029: 9930: 9914: 9903:

OK, I've removed that item. I'd think the item that says "Use as little code as possible ..." should be removed as well, since it's not an accessibility issue either.

9347: 9312: 9142: 9127: 9028: 8626:

Thanks for fixing that alt text – agreed about the crappy placement. A lot of people were disappointed that WCAG 2.0 failed to specifically mention redundant text for

8139:

ACCESS should be policy without reservation. If this is the encyclopedia that anyone can edit, it had better be the encyclopedia that anyone can read as well. In fact

7390:

Under what circumstances does hiding text (in the regular articles, not navboxes) actually improve accessibility or reduce the quality of content? (As far as I know,

7149: 6871: 6853: 6674: 6649: 6478: 6074: 5429: 4730: 4716: 4565: 4501: 3817: 3242: 864: 696: 680: 651: 635: 615: 11332: 11283:) which may have a "flat list" and show me what the ideal "accessible" answer would be using the flatlist template? It'd be instructive to see what we get. Cheers, 10358: 10302: 9186: 8156: 8133: 7613: 7485:) opened up (as they were at one point after a template changed) should give you an idea of why collapsing can be preferable or even necessary. See the discussion at 6711: 5822: 5788: 5401: 5369: 4904: 4618: 4600: 3658: 3621: 3584: 3544: 2899: 2211: 2195: 2168: 1887: 1313: 1295: 1271: 1249: 247: 12468:

I do not doubt that you are correct, in fact I believe you are more knowledgeable on this topic than me. However, you are missing the point. The issues I raised is:

12017: 10153: 10129: 9558:

In data tables which are sortable, we link everything that's linkable on every instance. This guideline makes it clear that that approach is unacceptable, to whit:

9274: 8927: 8541: 8519: 8505: 7547: 7266: 7209: 7135: 7119: 7072: 6829: 6429: 6411: 3402: 3386: 3320: 2920: 2140: 2119: 1939: 1753: 1444: 685:

I'm not a great fan of wiki-markup in headings either, mostly because it can make a mess of edit summaries. The disadvantages of it usually outweigh the advantages.

12512: 12493: 12463: 10832: 10813: 9898: 9827:"Avoid putting links in section headings. Some screen readers, such as versions of JAWS prior to 7.1, have significant difficulty correctly rendering such headers." 9804: 9790: 9775: 9395: 9164: 9105: 9047: 9014: 8999: 8861: 8847: 8767: 8744: 8717: 8694: 8675: 8643: 8621: 8466: 8391: 8374: 8347: 8314: 8267: 8224: 8181: 8107: 8068: 8037: 7674: 7647: 7365: 7315: 7286: 7163: 7006: 6992: 6976: 6909: 6760: 6741: 6619: 6601: 5935: 5876: 5712: 5649: 5522:

I regularly convert explicit bold faux-headings to either true headings or to DL, as appropriate. A distinction is needed between a DL structure and mere bold text.

4870: 4753: 4661: 4584: 4416: 4109: 4084: 4066: 4052: 2571: 1039: 11592: 10728:

clarifications in this MoS. I'm so used to accessibility that I can't read this page as regular FLC editors will do, so your comments are much appreciated. Yours,

10012:

Good question. I'd be interested to know why it was added to this MoS. This advice is supposed to improve readability, and has nothing to do with accessibility. I

6528: 5338: 5301: 3902: 282: 12313: 8587: 8443: 7195: 7177: 6890: 6633: 6557: 6514: 6445: 6186: 4827: 1202: 271:

I'm on JAWS 8 now, which is the earliest version that most people would use these days. It's not a problem now ... IIRC it ceased to be an issue around JAWS 7.1.

12439:

Larger tables benefit from having row headers marked up (whatever column they are in), so we should be aiming to educate editors in those benefits as a priority.

9428: 9414: 9242: 9037:

on the filesize, which is only an accessibility issue for those on low-bandwidth connections. Reducing the colour depth provides a big improvement (155 kB -: -->

8971: 8332: 6732:

tag around your strike trough and insert a correct deletion after it, or will you change earlier comment at the risk of confusing readers? :D I feel soooo evil!

2952: 2798: 2085: 1051: 784: 101: 93: 88: 76: 10489: 10247: 9230: 9034: 8427: 5579:

I don't have time to reply thoroughly on the content as I work tomorrow, and I'll have to get up in about 7 hours. But please, Jack Merridew. Please read again

4466:(such as JAWS 6.0 released in march 2005). I guess some inappropriate use may cause problems. I don't know enough details yet to provide a complete explanation. 4398: 3788:

The text '|-style="display:none"' causes problems for screen readers with no CSS support at all (which are very uncommon these days), and text browsers such as

11474: 11224: 10413:

We do have the guidance "Symbols that cause problems for screen readers may already have templates created to substitute an image with alt text. An example is

9680: 8630:, but WCAG were trying to remain up-to-date longer by being more technology neutral (and to be fair, modern screen readers will find the links associated with 7770: 6818: 5856: 5730:

text-formatting features at the beginning of one or two paragraphs on each page -- merely to help readers keep their place on the page, not to provide content.

4893:

the latter) is beneficial enough to justify ignoring the advice. Temporarily commenting the section out pending discussion seems the appropriate step to me. --

3259: 2862: 2340: 2328: 387: 71: 63: 11038:

using Frietje and Dodoïste's revisions to the Georgia template. I believe we are converging on something very useful. Thanks for all the help and comments!

10253:

I think that would be helpful. As a convenience for others, here's the link to a previous archived discussion that examines the general issue in some detail:

7341: 7154:

Which takes us back to the question of how to expand ascii text abbreviations for screen readers. It would be nice, but I haven't seen a foolproof way yet. --

5101:

little evidence for the need and little guidance available to the uninitiated, it is unlikely that the community would be in favour of a mass depreciation. --

3808:

I don't understand why you need to hide a row. Could you provide an example of use for this technique? Maybe we can find better solution than hiding the row.

3782: 2666: 1995: 446: 11007:

I made some big changes to the table. I added a table caption, column and row headers, and such in order to transform it into a standardized data table. Now

10639: 10567: 9547: 7872: 2639: 12484:

Another possibility is to merge the number and the name of the contestant. To merge the first and second column. What do you think about this idea? Cheers,

12056:

true but many projects have their own style guides and unless a project page is being pushed through FAC or FLC, there's no mandate for them to comply with

11935: 10059: 9883: 8604:

tags. This is suboptimal. Software issues, software issues again... When will the Wikimedia Foundation employ an accessibility expert to fix their soup tag?

8258:

I was not able to find any mail related to our discussion in the public mailing list. Could you show me directly which mails you are thinking about? Yours,

5413: 5252:

I have seen comments that screen readers will ignore the Unicode ½ but are those assertions true? How does the template output (which expands to

203:, will stop reading the heading title when they encounter a link, and if the link is the first part of the heading title, they will only read the link text. 12363:

that are not meant to be enforced, for two reasons. Its priority is low, and I anticipated that enforcing it will produce such pointless conflicts. Yours,

9359: 8559:"Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map" 8480:, has an image with links on it . These disappear if I tell my browser not to display images. Can a screen reader handle this or does this need looking at 6436:

Nor is it spoken by the simple text-to-speech converters that I tried. I'd prefer either "Ace of Hearts" as text, or an icon with alt text as suggested. --

5521:

the markup generated by the usual apostrophe wiki markup is 'b' and 'i' elements, rather than 'strong' and 'em' elements, which is improper.</aside: -->

3769:. Also, this warning is not mentioned in your project page under Tables. Would someone familiar with screen readers clear up these issues here and/or at 2510: 222:

a problem for the current/recent versions, then maybe it should be redacted. Otherwise, the dilemma should probably be discussed in another forum to reach

9757: 6796:

should be merged, if that is possible. I made the former template accessible by adding alt text; the same approach should be used at the latter template.

3718: 2476: 12269:

Actually, the results are not as bad as I paint them. Lil'unique has been steadfastly chipping away at the issue (kudos, Lil!), and when you look at the

10138:"this page has been inactive for years and is believed to be outdated. It is kept as an archive and as an example of template accessibility improvement." 9579: 3447: 3148:) that all visual user agents I've seen render with strikethrough style. Do screen readers also not indicate semantic text attributes, such as emphasis ( 1088: 9957: 9538:

It would be worth mentioning at the general requirements for images, though. Let's refine this idea, I hope some regulars here will comment. :-) Yours,

8982:

image is already present in the text of the article, so anyone reading the article without images still has the information presented to them elsewhere.

8663:

Oh, and to answer Gnevin's first question. I could not reproduce your bug. What browser did you use? With Safari 5 if I disable images the links remain.

6807: 6167:

accessible tables. We will use more complex syntax only when it's unavoidable. I need examples to make sure we can't solve those cases in a simple way.

3565:

is that I'd prefer it if the film title was the first column, so I could automatically hear the film titles when I'm moving up and down the table. See "

3279: 1171: 11946: 10523:

articles which clearly are utterly inaccessible... Perhaps Jack has a solution? (turns on massive floodlight, pointed skyward, with J A C K on it... )

10399:, perhaps a dedicated page which we could link to with a brief explanation of why this is a good thing, how to use them, and which ones are available? 10013: 8723:

still use outdated browsers like IE6. If over 7% of "geeks/developers" are using IE6 to view W3S, how many more viewers are using it to view Knowledge?

5200: 2537: 9620:

That's not a problem because JAWS and other screen readers put each table cell on its own line, so adding a link doesn't change the flow of the text.

8147:, and recognise that. I do agree that the details of the implementation of policy are best set as guidelines, so a separate page may be the answer. -- 7050: 6392: 6032:

If it is accepted that this guideline/policy is under construction then others should not be trying to enfore a broken/incomplete Manual of Style. --

8489: 8276:

the clearest and simplest language appropriate for a site's content" which it inherits from WCAG 1.0. You'll find that WCAG 2.0 has replaced it with

7486: 7330: 3180: 2236: 1874: 1801: 601: 8203:

table that does not make sense when linearized) does not mention data tables does not mean we can ignore them. If you want WCAG references, look at

2831: 2186:

political correctness, but unfortunately this just happens to be one of those pages where even a typo can't be touched without a consensus.--

1925:

Accolades in film articles and filmographies in actors' and filmmakers' articles are usually displayed in tables. In these tables, I often see the

931: 10545:

Often images are placed in one section deliberately to "leak" into another, and I think this para in ACCESS tries to dissuade users from doing it:

4875:

The last paragraph should be true, but sadly isn't. The MoS is a de-facto requirement, as I have learnt many times to my cost when suggesting that

4845: 2334: 2234: 1871: 1178: 109: 4540:. We'll make a thorough review before taking any decision, but we might consider to just remove these warnings in the end. They seem unreliable. 2813: 2690: 1915: 11145: 9990: 9695: 8987: 8232:

I found several guidelines easier to read than WCAG 2.0 (that was the main concern when WCAG 2.0 was released) but none of them were up-to-date.

5137:

I still support this change. I suggest to make explicit link title, and replace "; an example of the output from a screen reader is demonstrated

3561:

They work very well, at least for me. I can activate the sorting links and the table sorts correctly. My only criticism about the works table in

2958:

Can you give us an example or two of changes you'd like to make, that are being opposed? As a general rule, if you're really getting opposition

1814: 9288:. Firsts comments and feedback are welcomed. As I am not a native speaker copyedit in sections marked as complete is welcomed too. ;-) Regards, 9019:

Thank you for your help. I will try to contact the user who created the timeline and see if there is a compromise we can meet. I appreciate it!

6230:

for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.

3491: 9279: 8144: 1361:

Aren't mirrors designed to use our content in order to profit from ads? I don't quite see why either ACCESS or the MOS should accomodate them.

10589:

Yes, this MoS needs to be clarified. Now that we removed irrelevant section, we have some more space to clarify the relevant sections. I just

9472: 5276: 3761:

I am not certain whether this caution applies only to rows made unsortable using class="sortbottom", or whether the text above means that the

3605:

The article is mainly a biography, and Rossen had a very eventful life as a politically commited filmaker and as being brought forward to the

2314: 11200:

is recommended here. I've never heard of it (in nearly six years of editing) so I thought I'd see where it's used. Currently, according to

8280:(in particular G3.1.5 which ironically breaks its own guideline). I know of no web designer who has found that an improvement. Knowledge has 7140:

Great, thanks Gnevin. Maybe the alt text could be improved by replacing "k, of hearts" by "King of hearts". Is that what you meant Graham87?

6092: 4178: 2521: 1828: 1190:

I've ever commented on MOS, I'm unsure how to proceed. Should I propose new text or wait for others to follow up on my request? Thanks! --

208: 10020:

this cleanup sooner or later. We already did several changes in two days, and those last two might be trickier than the rest. Kind regards,

8450: 8431: 7751:

Lynx is not the appropriate tool for testing table linearization, because it has a (minimal) table support (you can see rows and columns in

6498: 5261:) sound in a screen reader or look in a text-based browser like Lynx? Some guidance from accessibility experts would be welcome, thanks! — 9820: 9706: 8793:

If a person has turned off images in (at least some) regular, reasonably common, reasonably modern browsers -- say, because the person has

6008: 5939: 5930:

Can I just say that this is becoming a bit of a nightmare as discussions have popped up in several other places such as the FL listing for

5435:"Headers" should not, of course, be mimicked using mere bolding or mucking with the font-size. How about we get clear on what you did: you 4139: 3191:, the screen reader I use, it is possible to configure it to indicate attribute changes by chaging the voice or playing a sound, using the 2937:"It looks fine to me, prove it's a problem, prove it can be fixed, prove those people matter, I don't think WP:ACCESS applies in this case" 21: 10675: 10590: 10099:

Not directly related but I do think this re-visit of MOS (access) is a really good thing for us all. I hope to keep advocating ACCESS at

9718: 6834:

That guideline is primarily intended to explictly ban flags being used in prose. Something I agree with. However, in my opinion there are

5938:. It seems apparent to me that this page is undergoing and update which is perfectly fine. But then it isn't acceptable for projects like 4537: 4456: 1326:

Collapsibles cause a problem on printable versions and on Wiki mirrors; I don't know why it ended up at ACCESS, I thought it was at MOS.

12204:

but sadly have been met with an attitude of "we always do it this way, so it's up to the developers of screen readers to accommodate us".

11940: 10868: 8496:

requirements rather concerns templates and MediaWiki software. I don't have the time just yet, but it's definitely on my to-do list. :-)

5473:

of definition lists for the visually-impaired. Let's have a good look at what guidance should be given and try to formulate some wording.

4571:

rowspans make life difficult for readers using these simple sort of solutions in many tables on Knowledge. I've documented an example at

3453:

I don't think for a moment that Knowledge should abandon good spelling or grammar. I'm just not sure how important it is for the average

2825: 1920: 12324: 12245: 11461:

considering it's used 97 times across all of Knowledge - 3.6 million articles) we should really work out if this is appropriate. If it

8556:@Gnevin: Yes, all users should be able to access the links, even with images turned off. The older WCAG 1.0 Checkpoint 1.5 is specific: 2610:, we're having a debate over titles for infoboxes, and we would like some input from the accessibility contingent. Here's what I know: 1546:. To add some of the features (like the mini-browser sidebar that's my reason for keeping a copy of Netscape) to a current browser, see 808:

for example. More generally speaking though, including the template with the section header simply makes it more difficult for everyone.

8951: 8244:

related to data tables. In fact, no up-to-date accessibility guideline say anything about data tables linearization. No references, no

7864: 7762: 7271:

Without having to grumble about egg-sucking grandmothers, I'm perfectly aware of H86, and you'll note that the use of the <abbr: -->

5767:

I've done over 7,000 edits since March 2008, and while I have only the very vaguest idea of what Cascading Style Sheets are and may do

4432: 1958:

has taken a hands-off, no-edit-warring approach for years, although certainly a "most common" style exists, if you look through pages.

1045: 12355:

While you are right that it improves the situation for screen readers users, it makes it worse for sighted users. As you can see, the

12181: 7600:

Perhaps you could get your expert to comment on the issue of rowspans with text-only browsers. I've prepared a small demonstration at

4385:

Thanks for the comprehensive reply (I was going to ask about "scope="row"" next). I'll put your suggestion for reworking the table to

3792:. In these browsing environments, the marked text is displayed rather than hidden. I don't know if it's much of a problem these days. 2548: 1054:. I don't know how reverty the regulars there are, but I figured it could use more accessibility eyes over there, given the nature of 12433:

Column headers really ought to be compulsory, and are familiar enough to most editors that marking them up will rarely cause dissent.

11351:

The template is correct from an accessibility point of view, which is the most relevant aspect here. However, the layout produced by

10515:

That's fine for articles (like cricket ones) which can (and now should) select alternatives. Not so sure what we can do about, say,

9741: 9436: 9353: 6160: 6054: 5407: 3890: 3859:

I'd second that. I look for improvements because that's just the sort of editor I am, but the sort function sorely needs a revamp. --

3606: 1174:

which explains the behavior I observed above and seems to address most of the accessibility concerns related to collapsible content.

8954:. There was originally a timeline like this, but I had to remove it, since a featured list must meet all of the criteria, including 7755:). To test linearization, you should use an appropriate tool, like the Web Developer extension for Firefox (Miscellaneous menu : --> 2248:

There's no need for this page to provide a list of redirects; tags don't have to match the variety of English used in the article.

11201: 8571:

My only criticism of the image map is that the image has "Status iucn3.1.svg" as its alt text. Not exactly what one would hope for.

8188: 5863: 3368: 3364: 3344: 2302:. I figured I should mention it on this talk page because I based my rationale partly upon the accessibility guideline which says “ 7277:

in an ideal way, and common visual agents such as IE7 fail the test for H86 (although that's a minor concern). Hope that helps. --

5688:(let's create a dedicated help page for it, because there is a lot to write about it). When the table of contents is too long use 5591:"The markup generated by the usual apostrophe wiki markup is 'b' and 'i' elements, rather than 'strong' and 'em' elements" --: --> 2868:

talk-pages, or disambiguation pages (they're not considered articles, yet). Perhaps there was a compromise and someone concluded:

2067: 8882:, and a 'bad' image could result in a potentially fatal seizure -- then this person is currently unable to click on the links to 8797:, and a 'bad' image could result in a potentially fatal seizure -- then this person is currently unable to click on the links to 8421: 7291:

Yup, I'm aware of it too. I replied that way because I misunderstood your previous post. I thought you were still supporting the

6941:

as "hearts" - it says "ee". Graham will be able to tell you if JAWS produces better results. It would be interesting to see how:

4639:

I'm sorry I didn't make that clearer, but huge numbers of readers who are visually impaired are not blind. For example, I have a

1817:

of this as the outcome of this discussion (he pretty much suggested it). Does anyone have concerns with this plan of action? --

12209:

Lil's attempts to make progress are really commendable, but when that's countered by paranoid hostility and by personal attacks,

9686:

In short, overlinking is evil. But it has nothing to do with accessibility specifically, so I removed it from this page. Yours,

9405:. Nevertheless, other editors may be able to suggest further improvement, and I'd encourage the regulars here to take a look. -- 5199:

I've been looking around, but haven't been able to find an authoritive, definitive statement about how to deal with fractions.

2487: 2063: 1769:. Hopefully they'll either stick or be reverted and kickstart further discussion here. Thanks all for the feedback so far. -- 215:, is it unique to legacy versions? I would rather not download and install this program just to test it, and then uninstall it. 12252: 10972: 9889:

I fully agree. I also thought about removing this guidance long ago, but somehow forgot to do it. Thanks for bringing this up.

8524:

Semantically speaking, there is everything needed in the code of Template:Conservation status to be accessible. Afterwards, if

6548:

should work, but I'd need to see it tested on some screen readers. You might want to do the same to render K as "king", etc. --

5992:

And perhaps someone should advise the DISCOG folks to stand down for a couple of weeks, while we get these things sorted out.

2723: 9504:

Images with transparent backgrounds can only be used on pages where you know the page color is compatible with the image, but

8597: 6695:

for added text, as a courtesy to others who may be confused by other comments made before your amendment (which would show as

3054:

WIAFA has not dropped ACCESS; I'm not sure what you're referring to, but FAs must conform to MOS, and ACCESS is part of MOS.

8454: 5323:

My attempt to use ½ on a featured list was challenged, and I want to have some clear guidance on what method is preferred. —

3884: 2614:

Having titles/captions attached to tables, figures, and other such "boxes" is a generally regarded as good for accessibility.

1130: 1107: 841:

broken. I'm going to correct the section title in this edit summary though, and it should bring you correctly to the section.

526:

wikitext in headings is stated in many other Knowledge documents as well, pointing to here for an explaination (for example:

325: 288: 287:

Kewl! In that case, does anyone have a problem with me adding a parenthetical "but not the current version" as a modifier? —

241: 6592:

to be an abbreviation for anything. Best practice here is to use an icon with alt text. And thanks to Graham87 for testing.

11979: 9675:

Thanks The Rambling Man for the cleanup you have done in this Manual of Style (accessibility), it is much appreciated. :-)

7478: 7452:

How do you decide that you don't want to read text whose contents you know nothing about, because someone hid the contents?

4830:. Until we find clear evidence that there is still an issue with rowspan/colspan I feel it should be removed from the MoS. 3176: 2926: 2279: 1568: 1480: 1400: 9967: 8164:

I hope this solves the controversy. If it does, I will begin to work on this "accessible tables tutorial" next week or so.

6746:

Hehehe - t'as raison! I won't change anything more, at risk of confusing other readers. My only defence is that <s: -->

5382:

JAWS says "one half" for the first example and "one slash two" for the second one. I'd prefer the a notation like that in

1636:

To be fair, we're both overachieving English clubs whose fans don't realise just how close they have come financial ruin.

393: 12103: 12043: 11931: 11887: 11847: 11681: 11640: 11613: 11440: 8941: 5844: 5567:, where I mentioned the tables and how the guidelines should be improved (among other things). When I began to introduce 4736: 4455:

Please note that I didn't make any change to the paragraphs about colspans and rowspans. It seems quite old, for example

4133: 2567: 2506: 2450: 2393: 2359: 1280:, and I'm totally blind, so I'm not sure myself. People with severe vision impairments use commercial magnifiers such as 12436:

Very small tables (e.g two-column) work just as well without row headers, so they are certainly not worth arguing about.

11361:

needs to be refined. The layout I suggest would look like the other horizontal lists, possibly with normal bullets like

9442: 4097: 1399:

I'm very interested in the answer to these questions, as another editor and I have just spent a month greatly expanding

563: 12251:

On the practical side, the editor in question seems to use the "royal we", but I don't see any proof of involvement at

10749: 10424: 10211: 9636:

Okay, so can we say that overlinking in sortable data tables is just fine then rather than simply "do not overlink."?

9370:

The use of colors in tables (quote: "Be aware of WP:ACCESS when you say that some swords are noted in yellow or green")

8204: 7346: 7325: 4523:

Please note that I didn't remove the colspans and rowspans in the discography table above. And it is accessible indeed.

4485: 2601: 1155:

when browsing Knowledge, so I tried to "Print Preview..." the page and discovered that it expands all of the boxscores.

710: 9500:, which is a graph that uses 5 colors, which means the image is not viewable if the webpage uses any of these colors. 6307:

This is a usability concern, and is absolutely not related to accessibility. This is a very frequent misunderstanding.

600:

The brackets used in links never appear in anchors for section titles. See the HTML source of a deletion debate, like

11014:

If the looks of it is okay with everyone, I'd be happy to make a more general horizontal bar graph template. Cheers,

9971: 9814: 9459: 5838: 5440: 4983:

Rowspans in particular can cause accessibility issues; an example of the output from a screen reader is demonstrated

3706: 3266: 2870:"Resolution is fine if applied to articles, but don't make it affect the formatting of WP policy or guideline pages?" 2542: 1767: 1074: 1033: 915: 487: 184: 9745: 6997:

Well, that settles it for me. Icons+alt text is the most accessible solution. Apologies to WFC – he has it right. --

4492:. This is not really an accessibility issue though, since it makes it hard to understand for sighted users as well. 4057:

Hi. Thanks for your interest. In order for me to answer thoroughly, could you provide a link to the complete table?

3422: 2696: 2525: 2304:

Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text

11775:

Homogeneity is a desirable, but unnecessary restriction, which does not account for the limitations of HTML markup

10978:

as a starting point, so I will ask the authors of that template for some suggestions and help as well. Thank you.

10386: 10354: 10298: 9764:

particular piece of text as well. I don't have much time to work on this right now, and I'll be away until Friday.

8648:

I've just tested with IE 8, Firefox 3.5 and Safari 5 (I updated from Safari 4). They all have keyboard support for

8129: 6849: 6645: 6145: 6119: 5350: 5184: 5108: 5037: 5005: 4900: 4813: 4596: 4514: 4445: 3866: 3647:

give it about a 2.5. In the absence of automated methods for moving the columns around, I wouldn't worry about it.

3535:. I also use (X)HTML tables, sometimes containing numeric data. How do well all of these work in screen-readers? -- 2462: 1764: 1622:, which I had initially confused with Watford. Perhaps the navbox template won't print while other templates will. 1119: 416: 410: 340: 12072:

and it's worked wonders as, over there, we try our best to accommodate as many accessibility issues as possible.

9115: 8878:

So the problem statement becomes, "If a person using Firefox has turned off images -- say, because the person has

7628:

F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized

6895:

Before going into the details with abbreviations and icons versus unicode character, let's try something simpler.

6543:

to supply the required output, then you wouldn't have to update each article. As Happy-melon says, I believe that

10123: 9744:). At least one very experienced editor has found this apparent contradiction to be confusing and unhelpful (see 9700: 9519:

know what color the page is going to be then you won't know that the page color will be compatible with the image

9490: 9303:

Thanks Graham87! :-) It's very useful to see the corrections you make. You guys are my new english teachers. :-)

7756:

linearize page). That will certainly make it easier for you to figure out what table linearization is and is not.

7601: 6398:

Yup. Don't convey information by color alone. The unicode heart character might not be rendered correctly by all

6198:

for all text in a non-Latin writing system. Screen readers without Unicode support will read a character outside

4881: 2626:

Which factor weighs more than the other? Are there other accessibility factors at play? Your input is welcomed

1786: 1256: 1137: 9871: 8564:

Since each of the links in the image map has an equivalent link in the cells above it, it has become accessible

8074:

are addressing, and my own credentials and experience outside Knowledge are irrelevant here – just as are Lgd's.

3199:

indicates attribute changes by changing the voice by default, but not many blind people use that screen reader.

3144:

strikethrough in a discussion page most often denotes deleted text. This has a perfectly good semantic element (

2468: 11403:

could be improved in a decent amount of time. So it wouldn't be the best choice to remove it from the MoS now.

10037: 8192: 6138:

have to be used in conjunction with a row header, or can it also be used on an ordinary first cell of a row? --

5843:

Like I said above, I still have tons of thing to add and improve here. Should I write them in a subpage of the

5539: 5169:

ignored if deemed unreasonable or not in keeping with community's view on the benefits of a particular practise

4072: 3192: 423:

should probably be rewritten for clarity, though. The current content about screen readers isn't very relevant.

51: 17: 10768:

is informative, but leads to a page which is in no way related to the manual of style. Is this subsection of

8172:

to work together – I sincerely hope we will achieve that – we need a way to get to agree on something. Yours,

11949:. Since several people here know more than I about lists, and I'd be happy to have you look at it. Thanks, 11280: 9866: 9114:

I'm not sure how accessible they are, but infographics like this are usually best turned into imagemaps. See

8081:#1); the same high standard of presentation is no less true for tabular data. It is a fact that rowspans are 7752: 5678:

Sure, instead we could teach users to make a good use of definition lists. It will be hard though. I suggest:

5334: 5272: 4489: 3724: 3443: 3285:

Ah. After Noraft said on the FAC that he wouldn't post here, I see he has. Order of items in the lead says

2835: 2655: 2644: 2524:

about the future of this and others MoS naming style. Please consider the issues raise in the discussion and

1882: 1823: 1775: 1619: 1457: 1351: 1308: 1266: 1197: 12421:

to learn about the different ways screen readers can render tables and how we can make their choices usable.

11465:

then we need to start telling people about it. Otherwise it's a dead end and the approach needs refining.

10291:

The "plain" one looks a lot better in my opinion, at both 1280x800 and 800x600. I'd very happily use that. —

8990:. I'll see if I can add some simple alternative text to give screen readers a basic idea of what's there. -- 8301:

I apologise; I wasn't clear enough before. I didn't mail anything. I put all the examples and references at

7456: 5847:? So you could pick up any change you feel is ready to become part of the MOS, after you discussed it here? 12478: 12277:

in accessibility with time! – as the good practice seeps into the editing. So all is not lost <grin: -->

9374: 8649: 8600:. Except that in the source code produced by MediaWiki the image tag with the alt text is placed after the 8477: 8430:

to "Images or colors inside a table" makes the guidance clearer and more useful. Can I just point out that

7427: 6280:

and let me know what you think. Please do not edit the page but if there are errors do let me know. ... --

4589:

Could anyone suggest a decent firefox add-on for this purpose? I'm interested in doing a bit of testing. --

3695: 3250: 2754: 2733: 1944: 1903: 11871:

More false claims. I suggest that, if you wish to persist with this, we take it to one of our talk pages.

6310:"If viewed on a portable device e.g. mobile phone or iPod touch such pages often appear misformed." -: --> 9601:

Well, any recently promoted FL with a sortable table will have the traditional "overlinking" issue, e.g.

8962:, and I'm not exactly sure how to check. Any information or confirmation is much appreciated. Thank you! 8805:, etc., in the round dots at the bottom of the template? Do I correctly understand the problem report? 8701: 8289: 8252: 5983: 3742:, to ensure that each column has the desired sort mode. However, this technique creates tables that have 1600: 837: 12184:, which addresses the issue of WikiProject 'guidelines' that contradict the community-wide guidelines. 8574:@Dodoïste: We cannot afford to ignore current text-only browsers. That makes it our concern. Please see 5773:

Many of these already have classes associated with them that can be overridden in the individual user's

4617:

When testing with a screen reader, keep in mind that you are only doing it out of pure curiosity. It is

1276:

I said that scrolling lists could cause problems with magnifiers, not collapsible content. I only use a

12519: 12118: 12077: 11470: 11342: 11288: 11220: 11156: 10958: 10777: 10706: 10635: 10563: 10528: 10485: 10454: 10404: 10369: 10316: 10243: 10205: 10149: 10109: 9641: 9611: 9575: 7352: 6367: 4322: 420: 396:- participants in this project may have useful input to give which would be very welcome there. Best, 42: 11624:

That's a bad example, because "England" is not part of the list which includes London and Birmingham.

8819:

No. This is a Firefox-specific bug. And it's a browser bug. I mean, Firefox is at fault here, not us.

7431: 2729:, and one possibility might be to overlay the text? Another would be to replace it with a variant of 145:

This would be a significant change involving thousands of pages so I'm putting it out for discussion.

12334: 12270: 11985: 11984:

Is this part of the manual of style arbitary or not? I recently tried to make some access changes at

11230:

It's for marking up lists in the proper HTML format, so screen readers can detect them as lists. See

11185: 10001: 9951: 8472: 5931: 5564: 4961:

That said, I do take RexxS' concern on board. Perhaps the following would be a good interim measure?

3691: 2939:. The resistance is not just in articles, or guideline formatting, but also in template formats, and 2467:

Feel free to revert the removal of the general style guidelines category if you like, but please see

329: 292: 235: 10307:

Agreed, the plain one is better for scaling and appropriate for those tasks I envisage it for (e.g.

9506:

if you know what page color is going to be used then why does the image use a transparent background

8578:]. The fact that redundant links are already provided proves that there are measures we can take. -- 4089:

Your header is correct. :-) I checked with reliable sources to be sure. This syntax is supported in

2716: 2699:. The output generated by the EasyTimeline extension isn't very accessible for screen reader users. 1013:

maintainability problem of rather high severity, and one that's been vexing me for over four years.

8728: 8302: 7304:

F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information

7302:

and contains an example of technique with an icon and alt text. A more accurate technique would be

5343:(I can't speak for screen readers, but that last denominator is clipped in Firefox 3.6 as well.) -- 5142: 5138: 5128: 4984: 4702: 4607: 4572: 3674: 3172: 2515: 2481: 2275: 152: 5779:" suggests a workaround that almost no Knowledge reader can, as presently conformed, make use of. 5659: 5585: 1208:

It's worth noting that the default print CSS now uncollapses tables like this by default, anyway.

12099: 12039: 11927: 11883: 11843: 11677: 11636: 11609: 11436: 10610: 10540: 8879: 8794: 8255:

and made the tables conformed to the WCAG 2.0 requirements. What will you do to make them linear?

6103: 3743: 2848: 2563: 2502: 2446: 2389: 2355: 338:

I dunno, from Graham says it's not a problem of practical importance nowadays, so I was bold and

12447: 10262: 9840:"An internal link in a section heading does not give complications in terms of section linking." 8457:. Anyway, this case is quite complicated. I will provide details on this issue in the tutorial. 7778:

Here is a nice and perfectly accessible data table (really simple, without colspan or rowspan) :

7303: 7250: 7242: 6357: 5448: 3566: 1954:

tags immediately adjacent to the associated text, without an intervening (non-breaking) space.

763:

itself. For an example of anchors in section headers, and how it works for you, please click on

142:

1) Governor of Georgia 1971 – 1975 2) Preceded by Lester Maddox 3) Succeeded by George Busbee

124:

1) Preceded by Lester Maddox 2) Governor of Georgia 1971 – 1975 3) Succeeded by George Busbee

12454:

which give detailed explanations of the different modes whereby JAWS can render data tables. --

12327:

about a guideline, among members of this accessibility project. We need to discuss this issue.

12260: 12189: 11954: 11167: 11042: 10997: 10943: 10651: 10330: 10228: 9270: 9254: 9211: 9174: 8895: 8810: 7468: 7409: 7361: 5997: 5895: 5739: 4404: 4386: 3713: 3487: 3333: 3298: 3112: 3062: 2967: 2808: 2743: 2685: 2253: 2027: 1991: 1334: 11831:

Side issue or not; kindly refrain from making false claims about my position or capabilities.

8212: 7725:

is not a layout table, but a data table with only two main accessibility issues : the lack of

7253:

Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text alternative

5412:

I recently added a paragraph about the issue with headings made out of bold text and ";", but

4462:

Colspans and rowspans in headers used in my example above is accessible in recent versions of

4071:

Most discography articles use this basic layout for the tables, a reasonable example could be

3269:

which sparked a bit of a debate, as it is up for FA. The infobox contains Chinese characters.

3029:

show evidence of thinking serious about the problems, e.g. what about non-visual difficulties.

2307: 12538: 12152: 12114: 12073: 12013: 11466: 11338: 11284: 11216: 11152: 10954: 10773: 10702: 10631: 10559: 10524: 10481: 10450: 10400: 10365: 10312: 10239: 10145: 10105: 9637: 9607: 9571: 9453: 7443: 7031: 6896: 6838:

to make an exception for poker, an opinion that (judging by the lack of mention of it at the

6471: 6288: 6040: 6020: 5951: 3836: 3778: 3687: 2663: 1655: 1654:

Let alone another W FC that's over-achieved both on the field and on the edge of insolvency,

1213: 1167: 1068: 1027: 909: 621: 509: 481: 12553: 12489: 12368: 12309: 12215: 12211: 12206: 12201: 11408: 11313: 11266: 11175: 11121: 11019: 10921: 10852: 10828: 10733: 10683: 10598: 10193: 10169: 10090: 10055: 10025: 9986: 9894: 9800: 9691: 9543: 9480: 9343: 9328: 9308: 9293: 9196: 9138: 9086: 9010: 8909: 8857: 8824: 8763: 8713: 8671: 8617: 8537: 8501: 8462: 8387: 8343: 8263: 8177: 8064: 7890:

of criteria, which should become headers when rendered properly. Here's the rewritten table:

7643: 7571: 7377: 7311: 7262: 7205: 7145: 6905: 6737: 6597: 6407: 6260: 6172: 5909: 5852: 5708: 5598: 5425: 5282:

I'm not an expert, but I can tell you immediately that ½ is read by Opera as "one half" and

5150: 5059: 4919: 4835: 4796: 4726: 4630: 4545: 4497: 4475: 4412: 4105: 4062: 3898: 3850: 3813: 2757:

is that it's impossible to tell the time periods of the listed events with a screen reader.

2591: 1804:

most of the pertinant information over to the main MOS article. I further propose that the

10383: 10351: 10295: 9998: 9948: 9833: 9531: 9182: 9072: 8735:

advice from the guidelines, when we can all agree on many things that ought to be added. --

8126: 7627: 7587: 7494: 7434:

to do so) What confuses me though about your comment is that editors usually hide text to

6846: 6642: 6220: 6203: 6142: 6114: 6062: 5784: 5580: 5347: 5181: 5163: 5105: 5034: 5002: 4897: 4810: 4593: 4511: 4442: 4261: 4168: 4090: 3863: 3683: 3570: 3188: 2985: 2908: 2289: 2239: 1911: 1840: 1749: 1694: 1662: 1627: 1608: 1590: 1554: 1521: 1507: 1451:

decision on what should be in the MOS rather than basing it on unsubstantiated "facts". --

1440: 1366: 1226: 401: 231: 200: 6937:

So it is likely that there is little difference. Certainly Opera reads them the same, but

2407:

have serious issues, of which the most visible one is when to use long or short alt text.

1953:

this week that, in part, discusses whether we should require editors to place <ref: -->

8: 12401:

So what should we recommend? I suggest that we should be encouraging/persuading editors:

9940: 9553: 9403:

WP:Featured list candidates/List of National Treasures of Japan (crafts: swords)/archive1

9377:(quote: "Can you just check that saying "marked in red" in a map also meets WP:ACCESS?"). 8883: 8798: 7519:

Knowledge talk:Missing Wikipedians#Accessibility problem with the use of the admin bullet

6877: 6537: 6455: 5666: 5572: 4201: 3699: 3168: 3033: 3007: 2533: 2271: 1097: 780: 415:

I've just readded the point about not placing links in heading titles. It was removed on

349: 223: 191: 148: 11337:

If the template is problematic, it shouldn't be recommended for use in the MOS, surely?

5556:

In short, if you don't want this page to be removed from the Knowledge guidelines (like

5500: 12090: 12030: 11918: 11874: 11834: 11668: 11627: 11600: 11427: 11240: 11100: 11080: 11067: 11032: 10983: 10898: 10882: 10793: 10660: 10579: 10558:

just to be explicit that images should always be in the section to which they relate?

10075: 9925: 9909: 9770: 9656: 9626: 9591: 9238: 9149: 9123: 9024: 8967: 8887: 8802: 8682: 7527: 7130: 7067: 6987: 6802: 6681: 6424: 5692: 5527: 5452: 5396: 5225: 5084: 5017: 4930: 4782: 4740: 4711: 4560: 4193: 3798: 3789: 3653: 3579: 3509: 3463: 3454: 3426: 3397: 3353: 3315: 3237: 3205: 2894: 2841: 2763: 2705: 2554: 2493: 2437: 2380: 2346: 2225:

I am guessing that this complaint was supposed to be about the guidance concerning the

2206: 2163: 2107: 2075: 2049: 2007: 1950: 1902:

I was wondering if someone can clarify the resolution guideline for me, in relation to

1897: 1859: 1718: 1705: 1576: 1535: 1468: 1432: 1382: 1290: 1244: 1145: 860: 827: 691: 676: 646: 630: 610: 585: 553: 442: 364: 277: 173: 136:"Governor of Georgia 1971 – 1975 Preceded by Lester Maddox Succeeded by George Busbee" 130:"Preceded by Lester Maddox Governor of Georgia 1971 – 1975 Succeeded by George Busbee" 5629: 4844:

There is clear evidence that there is an issue with rowspan/colspsan, and Graham also

12256: 12185: 12165:

Good articles are not required to comply with this page, as you will see if you read

11950: 11588: 11397: 11355: 11328: 11302: 11254: 11194: 11039: 10994: 10939: 10257:. The method of replacing a non-ascii symbol by an icon + alt text is recommended by 9497: 9266: 9250: 9207: 9170: 8891: 8806: 7464: 7405: 7357: 7107: 6814: 6155: 5993: 5891: 5735: 5625: 5328: 5266: 5194: 4188: 3710: 3617: 3540: 3483: 3326: 3291: 3290:

not an access issue, I don't care how it's sorted-- we just need an answer for FAC.

3128: 3108: 3076: 3055: 3041: 2963: 2948: 2931:

I have found widespread resistance, all across WP, to changing pages to conform with

2916: 2877: 2805: 2740: 2682: 2424: 2249: 2191: 2135: 2115: 2096: 2040:" section to your initial comment, as I didn't realize that the example was using an 2023: 1987: 1955: 1327: 1152: 12418:

to structure tables so that row header headers make up the first column if possible;

12136:

for advice on how we can encourage editors to take up some of the access stuff... —

6655:

Eh, it won't .... carry on nothing to see here just a user making a fool of himself

12523: 12451: 12338: 12137: 12061: 11998: 11597:

Do you have any evidence if an accessibility issue being caused to sighted people?

11373: 11110: 11090: 11056: 10935: 10769: 10762: 10755: 10396: 9859: 9567: 9448: 9173:, who seems at first glance to be an eager new user studying computer science (see 8978: 8959: 8955: 8923: 8576:

Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard

8515: 8485: 8281: 8118: 8113: 7973:

table. WCAG can only help so far, but designers still have to engage their brains.

7635: 7439: 7430:

to allow a single key to expand/contract all hidden text on the page? (or to set a

7337: 7173: 7115: 7046: 7027: 6867: 6825: 6670: 6660: 6629: 6524: 6488: 6483:

Alt tags aren't read by screen readers are they? They are not printed out for sure

6463: 6388: 6281: 6238: 6033: 6013: 5944: 4823: 3832: 3774: 3023: 3015: 3003: 2932: 2671: 2659: 2295: 2154: 1797: 1793: 1209: 1062: 1021: 903: 796:(a page with a lot of text) to actually see the behavior that I don't like as much. 792: 751: 717:

While we're on the topic of funky section headers, is there any problem with this?

527: 501: 475: 392:

A discussion about the use of icons without any supporting text is taking place at

167:

recent event (i.e. who became the Governer of Georgia after 1975), is spoken last.

12549: 12485: 12364: 12305: 11404: 11309: 11262: 11171: 11117: 11015: 10917: 10848: 10824: 10729: 10679: 10594: 10189: 10165: 10086: 10051: 10021: 9982: 9890: 9796: 9687: 9539: 9476: 9339: 9324: 9304: 9289: 9192: 9134: 9082: 9006: 8905: 8853: 8820: 8759: 8709: 8667: 8613: 8575: 8533: 8497: 8458: 8383: 8339: 8259: 8173: 8060: 7639: 7567: 7373: 7307: 7258: 7234:

software to speak the abbreviation out loud. And the abbreviation will be useless.

7201: 7141: 6901: 6733: 6593: 6403: 6353: 6256: 6233:

Don't use unpronounceable symbols such as ♥, use an images with alt text instead

6168: 6102:

to the templates that create the table headers. We use rowspans a lot. Looking at

5905: 5848: 5704: 5594: 5421: 5146: 5055: 4915: 4910:

alternatives to rowspan/colspan. That is feasible and the benefits would be clear.

4831: 4792: 4722: 4626: 4541: 4493: 4471: 4408: 4101: 4058: 3894: 3846: 3809: 3325:

That's what we need to know-- can you adapt some wording for the guideline page?

2587: 12508: 12459: 12283: 12223: 11969: 11915:, which I started earlier today, not knowing this topic was already in progress. 11862: 11822: 11655: 11573: 10809: 10520: 10506: 10440: 10428: 10380: 10348: 10338: 10326: 10292: 10282: 10218: 9879: 9845:

and neater organisation of sections within an article, avoiding multiple uses of

9786: 9753: 9424: 9410: 9391: 9178: 9160: 9101: 9068: 9059: 9043: 8995: 8843: 8740: 8690: 8639: 8583: 8439: 8379:

We also have the "3RR" on the french Knowledge. I know. I won't make an edit war.

8370: 8328: 8310: 8220: 8152: 8123: 8103: 8033: 7722: 7670: 7609: 7583: 7490: 7282: 7191: 7159: 7002: 6972: 6886: 6843: 6756: 6707: 6639: 6615: 6553: 6510: 6441: 6227: 6223:, the most popular screen reader, Unicode characters are very difficult to read. 6195: 6139: 6109: 6070: 5872: 5818: 5780: 5758: 5645: 5553:

as a consequence of the long debates it was removed from the guidelines. Too bad.

5482: 5365: 5344: 5297: 5178: 5102: 5031: 4999: 4894: 4885: 4866: 4807: 4749: 4657: 4590: 4580: 4508: 4439: 4394: 4277: 4273: 4148: 4080: 4048: 3860: 3737:

The first unsortable row can also be a hidden row, with each element marked with

3421:

The item about spelling and grammar in the text section was directly lifted from

3019: 2981: 2794:

Sounds good. The other option would be to replace it with a modified version of

2635: 2412: 1907: 1836: 1745: 1709: 1690: 1658: 1623: 1604: 1586: 1572: 1550: 1517: 1503: 1476: 1436: 1424: 1362: 1222: 873: 727: 397: 12218:, you probably have to give it up as a lost cause. Life's too short, I guess. -- 11993:

before they even begin to list content. Additionally there's very little use of

8208: 7638:. His level of english is good enough (or should I say professional?). Regards, 6206:, the most popular screen reader, Unicode characters are very difficult to read. 4824:

clearly state that they are outdated and that it's no longer a problem with JAWS

3690:

and users customize article appearance with individual styles that deviate from

2091:

politically correct, but edits to the page are only allowed on consensus.--

50:

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

12166: 11744:

Claims to be familiar with the limitations of HTML lists in regard to headings

10417: 9729:

So, while I appreciate the fact that italic text may substitute for colour for

8078: 8052: 7080: 6793: 6399: 5887: 4463: 3473: 2529: 2472: 2369:

Requirement for alt attributes removed from Featured article candidate criteria

2325: 2311: 2267: 1935: 1093: 805: 776: 531: 457: 345: 307: 260: 12394: 9321:

Knowledge:WikiProject Accessibility/Manual of Style draft/Data tables tutorial

9286:

Knowledge:WikiProject Accessibility/Manual of Style draft/Data tables tutorial

8059:. The risk is to have this recommendation removed from the MoS. Kind regards, 6345: 6340: 5292:

is read by Opera as "one vee two". What screen reader did you have in mind? --

4981:; they should not be used in an overly confusing or purely decorative manner. 12069: 12057: 12024: 11236: 11063: 10979: 10894: 10878: 10789: 10656: 10619: 10575: 10235: 10100: 10071: 9921: 9905: 9865:

by replacing many of those with direct links within the section headers. See

9766: 9652: 9622: 9587: 9382: 9284:

Hi. As promised most important parts of the table tutorial are now complete:

9234: 9191:

Yes, the precise dates are needed in order to convert into a table. Regards,

9119: 9020: 8963: 8890:, etc., in the round dots at the bottom of the template." Is that correct? 8358: 8352:

I understand English may not be your first language, but at present there is

8233: 8056: 7868: 7766: 7523: 7394: 7126: 7100: 7090: 7063: 7058: 6983: 6859: 6835: 6798: 6789: 6608: 6502: 6420: 6251:

Great idea, I support this change. I would add: "don't use symbols such as ♥

6058: 5979:

Perhaps it would be simpler and equally effective to put a banner similar to

5557: 5549: 5392: 5385: 5311: 5218: 5207: 5168: 4707: 4556: 4213: 4153: 3794: 3747: 3649: 3575: 3562: 3532: 3528: 3505: 3459: 3393: 3349: 3311: 3233: 3201: 3011: 3010:. This version was based on the idea of "physical descriptions". In May 2010 2890: 2759: 2701: 2650: 2416: 2408: 2404: 2341:

Knowledge:Village pump (policy)#Policy of using Transparent image backgrounds

2202: 2159: 2071: 2045: 2003: 1855: 1760: 1714: 1490: 1420: 1378: 1286: 1277: 1240: 1159: 1055: 844: 811: 731: 687: 660: 642: 626: 606: 569: 537: 426: 360: 273: 169: 163: 10347:

Nice work. I've implemented both on the lists I know I've used daggers in. —

7550:

soon. And I will provide relevant techniques to produce accessible tables.

6326: 4993:

the other hand, asserting in the MoS that they are harmful without proof or

3609:. I would suggest that the years therefore important, as some locate events. 985:

heading code in the HTML, but not ToC it. Under this scenario, I think that

604:, for proof. The relevant code is below the line with "edit section" in it. 254:

Not quite sure what screenreader Graham is on, perhaps he could comment... –

11584: 11385: 11324: 11209: 10308: 9849: 8362: 8140: 7184:

There isn't a foolproof way of getting ascii text to read as something else

6819:

Knowledge:Manual_of_Style_(icons)#Do_not_use_icons_in_general_article_prose

6665:

Awe I remembered, abbr don't print out but we have had both it would be ok

5324: 5262: 4876: 3828: 3770: 3730: 3613: 3536: 3265:

should go in an article? Before the infobox, or after? As an example, take

3072: 3037: 2944: 2912: 2873: 2420: 2187: 2130: 2111: 2092: 1877: 1818: 1805: 1770: 1452: 1428: 1345: 1302: 1260: 1191: 1186: 1126: 1108: 11778:

The list item acting as a header will be a label for the set of list data

11323:

used widely. Thus I always use bullet characters which avoid the problem.

11232:

Knowledge talk:Manual of Style (accessibility)/Archive 10#Horizontal lists

9441:

If anyone's an old hand at SVG maps and has some time to kill, please see

8532:

tag is none of our concern. It's their job, we can't do a thing about it.

7626:

If I'm not mistaken, table linearization only concerns layout tables. See

6687:

Dodoïste, when you change earlier comments, it's conventional here to use

6335: 3137:

Knowledge talk:Manual of Style (accessibility)/Archive 1#Striking text out

10395:

Agreed, hence the origins of this thread. If not discussed in detail on

8919: 8511: 8481: 7333: 7295:

solution. Sorry about that. Nice to see you are able to use the WCAG 2.0.

7169: 7168:

No because it would be read a k, King of Hearts which doesn't make sense

7111: 7042: 6863: 6821: 6666: 6656: 6625: 6520: 6484: 6384: 6234: 5319: 4158: 3573:; many other screen readers have copied its table-reading functionality. 3378: 3271: 3104: 562:

There, I rewrote the point to (hopefully) better represent the problems.

12386:

shows W3C's recommendation to mark up the cells in the second column as

12379: 9063:

headers. There are several free Wikimedia-user-created programmes (e.g.

6638:

Apologies if I'm being dense, but why would printing 2♥ be an issue? --

5439:

your new bit to the guideline and immediately used it as a rationale to

3450:

inspired me to create a Knowledge user page mentioning that I am blind.

2322:

Knowledge:Templates for discussion/Log/2010 February 26#Template:Tooltip

12504: 12455: 12279: 12219: 12065: 11965: 11858: 11818: 11730:"England" is not part of the list which includes London and Birmingham 11651: 11569: 10805: 10502: 10436: 10334: 10278: 9875: 9782: 9749: 9420: 9406: 9387: 9156: 9097: 9039: 8991: 8947: 8839: 8736: 8686: 8635: 8579: 8435: 8366: 8324: 8306: 8277: 8216: 8148: 8099: 8029: 7666: 7605: 7482: 7278: 7187: 7155: 7041:

Ok changes made. Can someone with a screen reader tell us how it reads

6998: 6968: 6882: 6752: 6703: 6611: 6549: 6506: 6437: 6066: 5868: 5814: 5754: 5641: 5571:

in the guidelines about tables I told Danny B. (a fellow member of the

5478: 5361: 5293: 4862: 4745: 4653: 4611: 4576: 4390: 4173: 4076: 4044: 2676:

Is it possible to specify alternative text for the images generated by

2631: 2619: 1809: 1581: 1494: 1485: 1416: 1412: 1406: 3423:

a message I wrote about accessibility nearly four and a half years ago

1539: 1530:

Netscape still keeps a shadowy existence as part of the AOL universe (

1502:

to a personal account indirectly linked on a user page), let me know.

8852:

The two first sentences are correct. The third needs a citation. ;-)

8245: 7351:

Scrolling lists and collapsible boxes cause problems for people with

6215:

Screen readers without Unicode support will read a character outside

5618:

I think I can find the W3C examples you were thinking of – see below.

5563:

At Wikimania, I held a conference about accessibility and Knowledge:

4640: 3908:

In the following example, would the "scope=" also go where indicated?

3676: 3425:. I've taken the opportunity to clarify that it's only applicable to 3196: 2753:

I think overlaying the text would be the best idea. The problem with

1931: 1547: 937: 471:

The developers could easily fix that with another escaping filter. —

302: 255: 9709:

on alternative methods of providing information conveyed by colour:

7331:

Wikipedia_talk:Username_policy#Are_symbols_as_usernames_allowable.3F

3417:

My tweaks to the item about spelling and grammar in the text section

11733:"England" is part of the list which includes London and Birmingham 7245:

Providing text alternatives for ASCII art, emoticons, and leetspeak

6519:

I agree the best way is to replace them with an Icon with Alt text

5936:

Knowledge talk:WikiProject Discographies/style#Accessibility issues

5466: 4622: 4219: 4183: 3103:

I support the general prohibition of color-on-color text. We want

1281: 301:

Probably best to just say "such as versions of JAWS prior to 7.1" –

211:

that raises the question of whether or not this is still an issue,

11308:

produces such an ugly layout, I can't show you the result easily.

10650:. The template also has other non-accessibility-related uses; see 10273: 9358:

Hi! I am new to WP:ACCESS and am trying to figure out how to make

8607:

Hmm... I'm quite surprised to see that those links created by the

2551:, where input from people with accessibility expertise is needed. 1004:

The rationale for doing any of this at all, of course, is that it

11379: 10132:. I checked the link out, but that very page says, as an intro: 9169:

I think it would be far easier to work with the table's creator,

8510:

But shouldn't users using text only browsers seen the links too?

8305:. Please let me know if there's anything you can't find there. -- 7852:

not visually rendered by a conforming agent (screen reader), the

6216: 6199: 6187:

Wikipedia_talk:Manual_of_Style_(accessibility)#Non_standard_ASCII

4625:

techniques, and aim for the AA accessibility level. That is all.

4163: 3439: 3434: 3036:. That takes time and multiple editors. If needed, have a RFC. -- 2263: 836:

This very page/section is a good demo of the problem, now. Go to

209:

Template talk:PRODWarning#Linked article name in section headings

10255:

WT:Manual of Style (accessibility)/Archive 11#Non standard ASCII

8319:

I've reverted your removal of the guidance and explanation from

7832:

This is the real table linearization, which doesn't make sense :

6418:

It's not a good idea. I can't read the hearts symbol with JAWS.

5675:

Add to it that most uses of definition list are for layout only.

5416:. This paragraph is the translation of the first section of the 5054:

I support WFC's proposal. I believe it's a good starting point.

3444:

With New Technologies, Do Blind People Lose More Than They Gain?

2962:, then you might have misunderstood the community's position. 1259:. I could expand and collapse the content without incident. -- 1129:. This has lead to some interesting discussion on the template 10787:

You're right, it's probably not relevant to web accessibility.

10573:

That's probably a good idea. Yes, your explanation is correct.

6533:

The safest way would be to alter the penultimate four lines of

6322: 3161: 1575:

3.6 (Jan. 2010) behaves in essentially the same way as that of

1543: 11947:

Knowledge talk:Manual of Style (lists)#Complex_list_formatting

10497: 9562:

Do not overlink. Screen readers put each link on its own line.

9526:

and not assume the website is in control of the presentation.

8288:

Now, there's a lot of improvement available for the tables in

8251:

But if you still insist, go ahead and try. I've just improved

6346:

Karo Caran: "An Introduction to Screen Magnification Software"

5131:. Editors should take this into account when designing tables. 4987:. Editors should take this into account when designing tables. 4538:

the whole warning was added by Thisisnotatest in november 2008

1876:. Thanks to everyone who participated in this discussion. -- 344:

the prohibition. Please feel free to revert if I overstepped.

10516: 9603:

List of National Basketball Association season steals leaders

9362:

more accessible. Two issues have been raised in the (active)

6454:

Spelling out every card is totally impractical on pages like

6332:

If you like videos, I found those to be really mind-blowing:

4735:

That's an excellent idea, Dodoïste. I see you're a member of

3686:, to what extent and under what circumstances can individual 3157: 2490:

has an accessibility component. Your views would be welcome.

1089:

Knowledge talk:Alternative text for images #Transcribing text

11750:

Andy is unable to explain how "England" should be marked up

10934:

I wonder whether you'd consider describing this approach at

10267: 7298:

I chose the previous reference because it is detailed about

1472: 1140:

as my test case which makes extensive use of this template:

12426:

Now we all know that most of the time TH and SCOPE are not

11945:

I have asked a question about formatting a complex list at

11205:

advocating its use. To be fair, it's currently borderline

10625:

template? All I see here that it renders the same text as

10593:, but I'm not conviced by my attempt. Any help is welcome. 10258: 8525: 8117:

effort is proportionate to the benefit. My opinion is that

7974: 7559: 7555: 7356:

people with one of the most common physical disabilities?

7241:

If you want to learn more about alternatives to ASCII, see

6318: 5904:

OK, I'll do it that way then. Thanks for your advices. :-)

4739:– would the development of a FAQ be best undertaken there? 4701:

about as good as that of JAWS. As for the table example at

3753:

Alternatively, the entire row can be marked as hidden with

2832:

WP:Village pump (policy)#The use of colors in filmographies

1531: 1499: 11761:

Tables and lists are intimately connected data structures

11424:

in its HTML) horizontal list where you have used bullets.

11009:

Template:Georgia, Largest cities, 2009 Census -- Bar Graph

10875:

Template:Georgia, Largest cities, 2009 Census -- Bar Graph

9970:. Users decided to change it. Now you need to add to your 9705:

At present, we have the following guidance at the section

8948:

timeline of the list of Red Hot Chili Peppers band members

8215:

that there are areas that it does not cover adequately. --

7513:

Accessibility of the lists at the Missing Wikipedians page

3071:

That's a surprise, as sound clips would also be needed. --

2155:

the section on varieties of English in the Manual of Style

12522:) which is making an effort to become more Accessible. — 11736:

A header should be associated with the data in its scope

10130:

Knowledge:WikiProject Accessibility/Infobox accessibility

9064: 7748:) attributes in order to associate header cells and data. 7548:

Knowledge:WikiProject Accessibility/Manual of style draft

5686:

Knowledge:Manual of Style (accessibility)/Definition list

5504:

quite a lot, too, and have revered me elsewhere, as well.

3442:

well, are poor spellers. See the New York Times article "

2403:

Removed from Featured article candidate criteria because

10435:

should be made, and referred to in the guidance here. --

10212:

Knowledge:FLC#Philadelphia Phillies_ all-time roster (C)

7538:

Rowspan and colspan, answer from an accessibility expert

3391:

I've responded there to avoid discussion fragmentation.

883:

and want additional links to it, you can't just do this

12325:

Talk:American Idol (season 10)#Tables_and_accessibility

12246:

Talk:American Idol (season 10)#Tables_and_accessibility

9733:

viewers, it seems to be unsuitable as a substitute for

7106:

in the middle of sentence would certainly fall foul or

6271:

Is my essay on accessbility suitable for music editors?

5499:

I expect their first language is French, and per their

5162:

project-wide consensus, clearer, and more difficult to

976:

would create a heading that looked like the results of

12319:

Number in the first column of a data table controversy

10214:, which included the "invention" of templates such as 9681:

Knowledge:WikiProject Usability/Readability guidelines

6458:. Is there any way to apply alt text to text? Maybe 6219:

as a question mark, and even in the latest version of

6202:

as a question mark, and even in the latest version of

6163:, you may find more information in the months to come. 4407:

to my watchlist and I will follow the discussion. :-)

3363:

As per your comment ("that part of the page defers to

3309:(EC) It doesn't matter to me as a screen reader user. 2062:

The discussion headings in question, seem to be here:

1689:

would need to access links that might not be able to?

358:

I don't have a problem with the removal of that text.

12333:: To say it frankly, the case you are bringing up at 9038:

32 kB), so may make the image more acceptable. HTH --

3694:? Interested contributors are invited to participate 3002:

In mid-Mar 2010 1 editor rushed through a version of

2044:

until I looked at the diff. Revert/fix at will :) --

9360:

List_of_National_Treasures_of_Japan_(crafts:_swords)

5734:can be done at no cost to our non-sighted readers? 5414:

I was reverted because there was no prior discussion

5224:

poorly, especially within tables, and discussion on

4976:

are best used in cases where they simplify the table

936:

What we really need is a new syntax of some kind in

12382:where there is an example given of this very case. 9978:div.references { font-size: 100% !important; } 6716:Thanks for reminding me RexxS, I forgot. Actually, 5813:

markup into huge numbers of individual articles. --

5769:(no, I'm not asking anyone here for an explanation) 1538:, the web browser, was discontinued in March 2008 ( 12359:does not mention this criteria. I moved it to the 10968:structure for creating the bars was created using 10007:12:44, 16th day of January in the year 2011 (UTC). 9981:It should work, let me know if it doesn't. Yours, 9566:Are sortable data tables exempt from this part of 9419:Thanks a lot for your feedback! Much appreciated. 8790:I want to make sure that I understand the problem: 6862:in this case also but just make users aware of it 6341:Victor Tsaran: "An Introduction to Screen Readers" 6154:Thanks for your efforts, Imzadi1979. Your edit to 5581:10.3 Definition lists: the DL, DT, and DD elements 4884:in preference to the yellow and red card coverage 1115:Someone recently suggested they might try to have 1050:I was shocked by some of what I read in there, so 765: 11202:this tool which counts transclusions of templates 11170:? If so, you could support the proposal. Cheers, 9996:Thanks. I still can't see why we are doing this. 7487:Template talk:Ahnentafel top/Requested Comments 1 6981:JAWS reads all three examples as question marks. 6919:1) ♥ 2) ♥ or 3) &hearts; 4013: 2838:. Please join in that discussion if you so wish. 2068:WT:MOS#Needed help regarding WP:Logical quotation 620:Piped links don't show up in anchors either, per 199:Some screen readers, such as earlier versions of 12244:What a discouraging conversation you link to at 12182:Knowledge:WikiProject Council/Guide#Advice_pages 11106:instead, when possible. Or change significantly 9737:viewers (under default screen reader settings). 7426:Do you suppose it would be useful to modify the 6624:Don't forget wiki is meant to be printed also ! 6499:Knowledge:Manual of Style (accessibility)#Images 5201:WP:Manual of Style (dates and numbers)#Fractions 2200:Precisely which sentence are you talking about? 2086:Potentially Culturally offensive American bias. 1961:The systems under consideration look like this: 1467:On the last version (9) of the now-discontinued 771: 139:which would be coded in the following sequence: 118:1) Preceded by 2) Name of office 3) Followed by 4857:against the use of these elements is available. 3107:readers to be able to read our articles, too. 2064:WT:MOS#Contradiction regarding inline citations 996:(i.e., parameters after the first ignored) but 759:section, whereas I want it to link to the word 10754:I'm not sure what this section has to do with 9968:MediaWiki talk:Common.css#Regarding references 9496:image itself uses. Take for example the image 9338:Since nobody replied I just made the changes. 9229:Just a question. Would we need to include the 6336:AssistiveWare videos on computer accessibility 5662:, you won't be able to do it without changing 4488:. For example, right before he came to fix it 4098:updated the example on David Bowie discography 3733:, but I'm worried about something said there: 2863:Loophole as Resolution under Article structure 887:, or yes, it will break. You have to do this: 734:for ages, and now that I've replaced it with: 388:Icons without supporting text - input required 11166:Is you idea the same as the one suggested at 7935:mimic properly the display rendered in Lynx). 7251: 7243: 6842:FLC) appears to be reasonably widely held. -- 5145:." Just a small fix, no content changed. :-) 4954:that took the initiative after discussion). 1796:. The originial contributor of the section, 1475:), which rode on the then-current version of 960:can thereby by given additional anchor id's. 566:, and feel free to copy edit it or change it. 12180:In the instant case, you might like to read 8236:is basically the WCAG 2.0 made easy to read. 7860:attributes are enough to make it accessible. 2110:, as that deals to when UK / USA English. -- 11997:and an apparent disregard for color etc. — 10873:I would appreciate any comments concerning 9530:on a transparent background are invisible. 9005:would be unproductive on the long run. ;-) 8354:no recommendation against rowspans/colspans 6372:Any guidance on non standard ASCII such as 4619:not a reliable method to test accessibility 3569:" for information about how tables work in 1599:Could you do the same test on the boxes in 1125:deleted claiming that it's in violation of 500:The discussion is just two sections above! 8229:So I'll make this table tutorial then. :-) 7182:Yes, because that's the point I'm making. 5797:h2 { font-size: 180%; font-weight: bold; } 5143:example of the output from a screen reader 2719:about it. I am working on a solution for 1763:and made the following minor adjustments: 891:. The heading will link perfectly fine as 12390:. I think we all are in agreement so far. 10615:Could we expand on why we should use the 9742:Philadelphia Phillies all-time roster (C) 9401:I'm not an expert, but I've commented at 8451:WP:Manual of Style (accessibility)#Images 8432:WP:Manual of Style (accessibility)#Images 6161:Knowledge:Manual of Style (accessibility) 4484:Hmm. I'm trying to understand by reading 4093:since JAWS 6.0 (march 2005), for example. 4002:This would give a table header like this: 3607:House Committee on Un-American Activities 3531:. I use a sortable table-like feature at 12342:but somehow you stuck at your proposal. 10427:for more". However, I've just looked at 10128:In the tables section there's a link to 9821:WP:Manual of Style (accessibility)#Links 9707:WP:Manual of Style (accessibility)#Color 8918:I don't get the links in IE8 or Firefox 8189:Royal National Institute of Blind People 7965:I hope you can see why linearisation is 5864:Knowledge talk:WikiProject Accessibility 5167:with consensus on this page, it will be 4612:Using NVDA to Evaluate Web Accessibility 3429:users. I've also removed the mention of 3365:Knowledge:Manual of Style (lead section) 3345:Knowledge:Manual of Style (lead section) 2781:[[Template:timeline row |timeline row ]] 2335:Harm done by transparent areas in images 110:Accessibility of preceded by/followed by 12323:There was a significant controversy in 12060:and no mandate for them to comply with 9746:User talk:The Rambling Man#MOS guidance 9719:WP:Manual of Style (accessibility)#Text 8958:. I'm not sure if this png file passes 8272:A table tutorial would be very helpful. 5418:French best practices for accessibility 4490:this table contained misuses of rowspan 4403:Thanks for asking. :-) I've just added 3448:one of my first major spelling mistakes 3231:. I'm not familiar with side comments. 2608:Manual of Style talk page for infoboxes 2375:Proposal to remove alt text requirement 2373:...despite my best efforts. Please see 2262:Besides, Knowledge, which is hosted in 1403:, which uses collapsed genealogy boxes 394:WT:FOOTY#National Team World Cup Tables 14: 12253:Knowledge talk:WikiProject Idol series 10819:users need to disable these shortcuts. 10016:, which I suppose is more appropriate. 9280:Accessibility table tutorial is coming 8950:using a png file, and added it to the 7602:User:RexxS/Accessibility#Linearisation 4129: 3934:rowspan="2" width="300"| Album details 3022:. To get acceptance, a new version of 2106:Which article(s)?. You should post to 1185:I would postulate that the verbage in 48:Do not edit the contents of this page. 12477:The accessibility issue was fixed at 12027:the pages in their area of interest. 11215:material. It'd be nice to know...! 9116:Knowledge:Picture tutorial#Image maps 8754:: "citation needed".</cynical: --> 8455:Knowledge:Alternative text for images 6093:Table guidelines and highway articles 5516:semantically meaningless; it's about 4457:this paragraph was added in July 2009 4132: 4126: 4123: 4073:David Bowie discography#Studio albums 4016: 4010: 3457:user who isn't a pedant like me. :-) 3367:"), I have posted about the issue in 2549:colours for species distribution maps 2070:(each has multiple subheadings). -- 10014:moved it to a page about readability 9443:Talk:Sexually transmitted disease#xs 8986:left as something to discuss on the 8977:The usage of the image doesn't meet 7712: 7479:Grandchildren of Victoria and Albert 5749:overridden in the individual user's 3006:in about a week, with no attempt at 1569:Grandchildren of Victoria and Albert 1542:). See also The Netscape Archive at 1481:Grandchildren of Victoria and Albert 1401:Grandchildren of Victoria and Albert 879:template documentation. If you have 775:(the version I don't like as much). 730:says this won't work, but it was in 29: 12395:Assistive technology reading tables 11941:Complex list formatting at WT:LISTS 11758:Tables cannot be compared to lists 11234:. I don't care about it that much. 10869:Partial replacement for a bar graph 9498:File:World-Population-1800-2100.png 8449:I finally did something right! :-) 5845:Knowledge:WikiProject Accessibility 5660:HTML element#Document body elements 5586:HTML element#Document body elements 3746:issues, as it causes problems with 2836:WP:ACCESS#Styles and markup options 2830:There is currently a discussion at 2826:Discussion regarding this guideline 1921:Font size and readability in tables 1540:http://browser.netscape.com/history 218:If someone can document that it is 207:There is currently a discussion at 27: 12357:accessibility data tables tutorial 12273:page, you can see that the tables 10425:Category:Image insertion templates 9872:his reply confirms my observations 9473:added advice for geographical maps 6317:To learn more about it, I suggest 6055:WP:WikiProject Discographies/style 5540:like I edited another one year ago 5317:output in a table when using IE8. 4610:(NVDA). See the article by WebAIM 4433:colspan and rowspan: issue or not? 3739:<span style="display:none": --> 2306:”. Please direct all responses to 1585:(family trees) referred to above. 1548:http://browser.netscape.com/addons 1046:Major change at alt text guideline 28: 12599: 11911:Please note discussion below, at 11028:Great! I went ahead and created 10648:quite passionate about this topic 9972:User:Rich Farmbrough/monobook.css 9823:we currently have this guidance: 9437:Colored map accessibility cleanup 9354:How to make this list accessible? 8598:alt text issue was trivial to fix 6327:Introduction to Web Accessibility 6319:Introduction to Web Accessibility 6253:use an icon with alt text instead 5565:First steps towards accessibility 5408:Visual headings should be avoided 3942:colspan="5"| Peak chart positions 722:== Thumbnails {{Anchor|thumb}} == 12393:But that W3C page has a link to 11421:correctly semantically marked up 11362: 10838: 10676:added the explanation to the MoS 10496: 10272: 10266: 10179: 7713: 6724:is the tag that goes along with 5318: 3765:is less troublesome in terms of 3705:Great, and can we put an end to 3501:TFD for the template in question 3267:St. Michael's Cathedral, Qingdao 2578: 1516:When was netscape discontinued? 315: 33: 12479:American Idol (season 10)#Males 12404:to mark up column headers with 11419:Please provide an example of a 8838:, then it becomes our fault. -- 8422:Images or colors inside a table 7969:an important consideration for 7699:Just to confirm a few things : 7200:@Gnevin: Oh, that's right. :-) 7096:handle a different roll .Using 3891:recent update of our guidelines 2469:WT:MOS#General style guidelines 1138:2009 Seattle Sounders FC season 804:noticeboard, like something on 755:links to the first word in the 12581: 12572: 12446:Finally, there are pages like 11772:List data must be homogeneous 11484:List of major cities in the UK 11076:Thanks for notifying us. Now, 10065:No objections from me. See my 9429:22:18, 17 September 2010 (UTC) 9415:21:50, 17 September 2010 (UTC) 9396:20:07, 17 September 2010 (UTC) 9348:16:58, 27 September 2010 (UTC) 9333:20:31, 26 September 2010 (UTC) 9313:13:07, 10 September 2010 (UTC) 9298:01:55, 10 September 2010 (UTC) 9275:06:27, 14 September 2010 (UTC) 9259:06:02, 14 September 2010 (UTC) 9216:06:02, 14 September 2010 (UTC) 8836:and don't do anything about it 7481:with all the ancestry tables ( 6960: 6949: 6562:This would be a misuse of the 6278:User:Lil-unique1/Accessibility 2660:Chris Cunningham (not at work) 2520:There is currently an ongoing 1210:Chris Cunningham (not at work) 1052:I overhauled significant parts 889:==Foo{{Anchors|Foo|Bar|Baz}}== 769:(the version I prefer) and on 766:#Anchor to this section header 18:Knowledge talk:Manual of Style 13: 1: 11913:#Horizontal lists in navboxes 11281:List of birds of Pennsylvania 11279:favour and find a list (e.g. 11275:Okay then, could you do me a 11146:Default "alt text" for images 11011:is completely accessible. :-) 10973:Infobox political party/seats 10067:previous musings on the topic 9958:12:05, 23 December 2010 (UTC) 9867:List of birds of Pennsylvania 9548:20:17, 16 November 2010 (UTC) 9243:15:26, 6 September 2010 (UTC) 9201:00:10, 8 September 2010 (UTC) 9187:22:29, 5 September 2010 (UTC) 9165:22:20, 5 September 2010 (UTC) 9143:22:10, 5 September 2010 (UTC) 9128:21:40, 5 September 2010 (UTC) 9106:21:34, 5 September 2010 (UTC) 9091:21:16, 5 September 2010 (UTC) 9077:18:05, 5 September 2010 (UTC) 9048:17:00, 5 September 2010 (UTC) 9029:14:41, 5 September 2010 (UTC) 9015:08:11, 5 September 2010 (UTC) 9000:06:41, 5 September 2010 (UTC) 8972:04:22, 5 September 2010 (UTC) 7400:does not change any content.) 5447:, I used a ';' to indicate a 3885:How to make accessible tables 3729:I recently added a method to 2724:Infobox political party/seats 2715:Yes, I just saw something at 2212:16:08, 20 February 2010 (UTC) 2196:16:03, 20 February 2010 (UTC) 2169:15:00, 20 February 2010 (UTC) 2141:13:14, 20 February 2010 (UTC) 2120:10:37, 20 February 2010 (UTC) 2101:08:53, 20 February 2010 (UTC) 2080:08:09, 14 February 2010 (UTC) 2054:08:09, 14 February 2010 (UTC) 2032:04:04, 14 February 2010 (UTC) 2013:03:37, 14 February 2010 (UTC) 1996:18:52, 13 February 2010 (UTC) 1620:West Ham United Football Club 1483:open out very nicely and the 1479:, the collapsed portraits in 865:19:19, 15 December 2009 (UTC) 832:19:15, 15 December 2009 (UTC) 785:18:25, 15 December 2009 (UTC) 749:the result isn't as nice, as 697:15:03, 15 December 2009 (UTC) 681:13:09, 15 December 2009 (UTC) 652:01:35, 15 December 2009 (UTC) 636:01:27, 15 December 2009 (UTC) 616:01:22, 15 December 2009 (UTC) 590:19:50, 14 December 2009 (UTC) 558:19:42, 14 December 2009 (UTC) 517:18:40, 14 December 2009 (UTC) 465:15:57, 14 December 2009 (UTC) 447:14:44, 14 December 2009 (UTC) 421:Knowledge:Accessibility#Links 12411:to mark up row headers with 12384:Example 1: A simple schedule 12378:You really need to refer to 11980:How enforcible is WP:ACCESS? 11578:01:03, 25 January 2011 (UTC) 11475:23:11, 18 January 2011 (UTC) 11413:21:30, 18 January 2011 (UTC) 11347:07:28, 18 January 2011 (UTC) 11333:01:29, 18 January 2011 (UTC) 11318:22:32, 17 January 2011 (UTC) 11293:22:07, 17 January 2011 (UTC) 11271:22:00, 17 January 2011 (UTC) 11246:07:59, 17 January 2011 (UTC) 11225:21:23, 16 January 2011 (UTC) 11086:is way more accessible than 10857:19:08, 17 January 2011 (UTC) 10833:19:05, 17 January 2011 (UTC) 10814:18:27, 17 January 2011 (UTC) 10799:07:59, 17 January 2011 (UTC) 10782:21:36, 16 January 2011 (UTC) 10738:22:26, 17 January 2011 (UTC) 10711:21:41, 17 January 2011 (UTC) 10688:21:38, 17 January 2011 (UTC) 10666:07:59, 17 January 2011 (UTC) 10640:21:30, 16 January 2011 (UTC) 10603:20:56, 17 January 2011 (UTC) 10585:07:59, 17 January 2011 (UTC) 10568:21:14, 16 January 2011 (UTC) 10533:21:43, 17 January 2011 (UTC) 10511:21:39, 17 January 2011 (UTC) 10490:20:58, 17 January 2011 (UTC) 10459:20:28, 17 January 2011 (UTC) 10445:20:24, 17 January 2011 (UTC) 10409:20:17, 17 January 2011 (UTC) 10391:20:02, 17 January 2011 (UTC) 10374:19:43, 17 January 2011 (UTC) 10359:19:42, 17 January 2011 (UTC) 10343:19:36, 17 January 2011 (UTC) 10321:19:17, 17 January 2011 (UTC) 10303:19:14, 17 January 2011 (UTC) 10287:17:58, 17 January 2011 (UTC) 10248:20:38, 16 January 2011 (UTC) 10198:19:07, 17 January 2011 (UTC) 10174:22:19, 16 January 2011 (UTC) 10154:20:16, 16 January 2011 (UTC) 10114:20:09, 16 January 2011 (UTC) 10095:19:44, 16 January 2011 (UTC) 10081:13:09, 16 January 2011 (UTC) 10060:11:46, 16 January 2011 (UTC) 10030:19:54, 16 January 2011 (UTC) 9991:10:29, 16 January 2011 (UTC) 9931:02:28, 16 January 2011 (UTC) 9915:02:24, 16 January 2011 (UTC) 9899:22:53, 15 January 2011 (UTC) 9884:22:39, 15 January 2011 (UTC) 9834:Help:Section#Section linking 9805:22:40, 15 January 2011 (UTC) 9791:22:19, 15 January 2011 (UTC) 9696:21:00, 15 January 2011 (UTC) 8650:Template:Conservation status 8478:Template:Conservation status 6956:<abbr title="hearts": --> 6945:<span title="hearts": --> 6917:(original editor's source:) 6897:Heart (symbol)#Computer code 6663:) 20:55, 4 August 2010 (UTC) 6566:tag. Semantically speaking, 6545:<abbr title="spades": --> 5804:User:Shakescene/monobook.css 4737:WP:WikiProject Accessibility 4621:. We should comply to W3C's 3482:works with a screen reader? 2927:Expecting extreme resistance 2755:Template:Horizontal timeline 2656:WT:AIR#Captions for line art 1980:Spaced <ref: --> 1940:16:00, 26 January 2010 (UTC) 1916:22:16, 19 January 2010 (UTC) 1888:03:52, 5 February 2010 (UTC) 1865:01:34, 4 February 2010 (UTC) 1845:01:13, 4 February 2010 (UTC) 1829:17:50, 3 February 2010 (UTC) 1781:20:49, 30 January 2010 (UTC) 1754:08:15, 30 January 2010 (UTC) 1724:07:08, 6 February 2010 (UTC) 1699:04:21, 5 February 2010 (UTC) 1667:04:58, 5 February 2010 (UTC) 1632:04:14, 5 February 2010 (UTC) 1613:09:06, 31 January 2010 (UTC) 1595:06:15, 31 January 2010 (UTC) 1559:18:36, 30 January 2010 (UTC) 1544:http://browser.netscape.com/ 1526:08:15, 30 January 2010 (UTC) 1512:02:17, 30 January 2010 (UTC) 1463:17:40, 29 January 2010 (UTC) 1445:03:12, 29 January 2010 (UTC) 1415:'s direct descent from King 1388:05:34, 30 January 2010 (UTC) 1371:22:46, 29 January 2010 (UTC) 1357:01:35, 26 January 2010 (UTC) 1339:01:20, 26 January 2010 (UTC) 1314:08:09, 25 January 2010 (UTC) 1296:04:22, 25 January 2010 (UTC) 1272:17:59, 24 January 2010 (UTC) 1250:05:41, 24 January 2010 (UTC) 1231:02:14, 24 January 2010 (UTC) 1217:12:32, 18 January 2010 (UTC) 1203:07:27, 18 January 2010 (UTC) 1102:07:59, 18 January 2010 (UTC) 1081:06:57, 18 January 2010 (UTC) 1040:07:21, 18 January 2010 (UTC) 992:produce the same results as 922:07:26, 18 January 2010 (UTC) 772:#Anchor to this section body 494:07:00, 18 January 2010 (UTC) 406:22:15, 27 October 2009 (UTC) 370:16:22, 24 October 2009 (UTC) 354:21:40, 23 October 2009 (UTC) 334:17:41, 23 October 2009 (UTC) 310:17:05, 23 October 2009 (UTC) 297:17:03, 23 October 2009 (UTC) 283:16:12, 23 October 2009 (UTC) 263:15:39, 23 October 2009 (UTC) 248:15:36, 23 October 2009 (UTC) 179:10:10, 12 October 2009 (UTC) 157:06:43, 12 October 2009 (UTC) 7: 11764:A table is a list of lists 10652:Template:Lang/doc#Rationale 10433:Category:Accessible symbols 9776:02:50, 4 January 2011 (UTC) 9758:17:47, 3 January 2011 (UTC) 9662:02:46, 4 January 2011 (UTC) 9646:15:57, 3 January 2011 (UTC) 9632:14:18, 3 January 2011 (UTC) 9616:10:28, 3 January 2011 (UTC) 9597:03:38, 3 January 2011 (UTC) 9580:19:17, 2 January 2011 (UTC) 9485:12:19, 9 October 2010 (UTC) 9466:05:01, 9 October 2010 (UTC) 8942:Question regarding timeline 8928:09:39, 31 August 2010 (UTC) 8914:11:51, 29 August 2010 (UTC) 8900:04:42, 29 August 2010 (UTC) 8862:01:12, 29 August 2010 (UTC) 8848:00:53, 29 August 2010 (UTC) 8829:00:34, 29 August 2010 (UTC) 8815:00:27, 29 August 2010 (UTC) 8768:01:12, 29 August 2010 (UTC) 8745:00:49, 29 August 2010 (UTC) 8718:23:59, 28 August 2010 (UTC) 8702:usage share of web browsers 8695:22:24, 28 August 2010 (UTC) 8676:18:48, 28 August 2010 (UTC) 8644:02:27, 28 August 2010 (UTC) 8622:23:35, 27 August 2010 (UTC) 8588:22:15, 27 August 2010 (UTC) 8542:21:04, 27 August 2010 (UTC) 8520:20:27, 27 August 2010 (UTC) 8506:16:39, 26 August 2010 (UTC) 8490:15:23, 26 August 2010 (UTC) 8467:11:49, 29 August 2010 (UTC) 8444:02:10, 29 August 2010 (UTC) 8392:01:40, 29 August 2010 (UTC) 8375:01:13, 29 August 2010 (UTC) 8348:00:45, 29 August 2010 (UTC) 8333:00:24, 29 August 2010 (UTC) 8315:00:01, 29 August 2010 (UTC) 8290:Usage share of web browsers 8268:21:36, 28 August 2010 (UTC) 8253:Usage share of web browsers 8234:WebAIM's WCAG 2.0 Checklist 8225:01:42, 28 August 2010 (UTC) 8182:22:41, 27 August 2010 (UTC) 8157:15:31, 27 August 2010 (UTC) 8134:14:47, 27 August 2010 (UTC) 8108:14:28, 27 August 2010 (UTC) 8069:11:02, 27 August 2010 (UTC) 8038:18:25, 26 August 2010 (UTC) 7873:08:33, 26 August 2010 (UTC) 7771:07:11, 26 August 2010 (UTC) 7675:02:12, 26 August 2010 (UTC) 7648:01:16, 26 August 2010 (UTC) 7614:01:34, 25 August 2010 (UTC) 7592:01:03, 25 August 2010 (UTC) 7576:22:48, 24 August 2010 (UTC) 7533:03:52, 27 August 2010 (UTC) 7499:08:19, 26 August 2010 (UTC) 7342:14:44, 19 August 2010 (UTC) 7316:12:47, 21 August 2010 (UTC) 7287:00:37, 17 August 2010 (UTC) 7267:23:16, 16 August 2010 (UTC) 7210:23:16, 16 August 2010 (UTC) 7196:23:06, 16 August 2010 (UTC) 7178:22:07, 16 August 2010 (UTC) 7164:20:06, 16 August 2010 (UTC) 7150:19:07, 16 August 2010 (UTC) 7136:14:56, 16 August 2010 (UTC) 7120:14:16, 16 August 2010 (UTC) 7073:14:09, 16 August 2010 (UTC) 7051:13:59, 16 August 2010 (UTC) 7036:19:01, 12 August 2010 (UTC) 6817:considerations here namely 6362:23:55, 16 August 2010 (UTC) 6298:23:23, 16 August 2010 (UTC) 6265:19:12, 16 August 2010 (UTC) 6243:14:07, 16 August 2010 (UTC) 6177:10:35, 14 August 2010 (UTC) 6150:03:41, 12 August 2010 (UTC) 6129:03:21, 12 August 2010 (UTC) 6075:23:29, 12 August 2010 (UTC) 6048:22:52, 12 August 2010 (UTC) 6028:22:50, 12 August 2010 (UTC) 6002:18:18, 12 August 2010 (UTC) 5959:02:02, 12 August 2010 (UTC) 5914:20:06, 10 August 2010 (UTC) 5900:03:22, 10 August 2010 (UTC) 5877:00:38, 10 August 2010 (UTC) 5862:You could use a subpage of 5823:04:34, 13 August 2010 (UTC) 5789:03:07, 13 August 2010 (UTC) 5763:00:26, 13 August 2010 (UTC) 5744:23:50, 12 August 2010 (UTC) 5713:20:03, 10 August 2010 (UTC) 5650:00:30, 10 August 2010 (UTC) 5189:02:59, 12 August 2010 (UTC) 5155:20:15, 10 August 2010 (UTC) 5141:" by "; as demonstrates an 5093:covered, failure is likely. 4828:Graham87 has just confirmed 3757:, which is probably better. 2935:. The typical response is: 1601:Watford F.C. season 2009-10 932:Proposed technical solution 711:Anchors in section headers 534:mention it, and link here). 10: 12604: 12520:The X Factor (UK series 7) 12448:Tables with JAWS and MAGic 11974:23:46, 28 March 2011 (UTC) 11959:19:41, 28 March 2011 (UTC) 11936:21:39, 28 March 2011 (UTC) 11892:23:40, 29 March 2011 (UTC) 11867:15:52, 29 March 2011 (UTC) 11852:13:24, 29 March 2011 (UTC) 11827:12:08, 29 March 2011 (UTC) 11686:00:09, 29 March 2011 (UTC) 11660:23:21, 28 March 2011 (UTC) 11645:21:24, 28 March 2011 (UTC) 11618:21:24, 28 March 2011 (UTC) 11593:20:32, 28 March 2011 (UTC) 11445:21:36, 28 March 2011 (UTC) 11367:For example in the navbox: 11180:22:41, 24 March 2011 (UTC) 11161:18:51, 24 March 2011 (UTC) 11126:22:32, 24 March 2011 (UTC) 11096:. So we should really use 11072:20:44, 24 March 2011 (UTC) 11048:01:29, 14 March 2011 (UTC) 11024:14:45, 13 March 2011 (UTC) 11003:05:03, 11 March 2011 (UTC) 10988:21:24, 10 March 2011 (UTC) 10963:21:01, 10 March 2011 (UTC) 10948:20:49, 10 March 2011 (UTC) 10926:20:46, 10 March 2011 (UTC) 10904:14:32, 10 March 2011 (UTC) 10887:01:25, 10 March 2011 (UTC) 10847:, I removed this section. 10750:Keyboard shortcuts section 10591:made an attempt to clarify 10188:, I removed this section. 9233:to the timeline, as well? 7978:rowspans? If not, why not? 7353:repetitive stress injuries 7347:Repetitive stress injuries 7326:Symbols in usernames a FYI 7007:15:12, 6 August 2010 (UTC) 6993:14:58, 6 August 2010 (UTC) 6977:14:53, 6 August 2010 (UTC) 6910:10:58, 6 August 2010 (UTC) 6891:22:47, 5 August 2010 (UTC) 6872:21:37, 5 August 2010 (UTC) 6854:14:35, 5 August 2010 (UTC) 6830:08:52, 5 August 2010 (UTC) 6808:01:26, 5 August 2010 (UTC) 6761:14:53, 6 August 2010 (UTC) 6742:11:05, 6 August 2010 (UTC) 6712:21:08, 4 August 2010 (UTC) 6675:20:58, 4 August 2010 (UTC) 6650:20:49, 4 August 2010 (UTC) 6634:20:43, 4 August 2010 (UTC) 6620:19:17, 4 August 2010 (UTC) 6602:16:57, 4 August 2010 (UTC) 6558:16:44, 4 August 2010 (UTC) 6529:16:23, 4 August 2010 (UTC) 6515:16:21, 4 August 2010 (UTC) 6493:16:14, 4 August 2010 (UTC) 6479:16:05, 4 August 2010 (UTC) 6446:14:34, 4 August 2010 (UTC) 6430:14:20, 4 August 2010 (UTC) 6412:13:10, 4 August 2010 (UTC) 6393:09:31, 4 August 2010 (UTC) 5934:and more significantly at 5857:21:51, 9 August 2010 (UTC) 5808:User:Shakescene/vector.css 5603:21:47, 9 August 2010 (UTC) 5560:) you'd better improve it. 5531:23:40, 8 August 2010 (UTC) 5487:22:56, 8 August 2010 (UTC) 5456:22:11, 8 August 2010 (UTC) 5430:20:16, 8 August 2010 (UTC) 5402:03:41, 6 August 2010 (UTC) 5370:15:06, 6 August 2010 (UTC) 5355:00:10, 6 August 2010 (UTC) 5339:00:02, 6 August 2010 (UTC) 5302:22:56, 5 August 2010 (UTC) 5277:18:17, 5 August 2010 (UTC) 5254:<span class="frac": --> 5113:22:53, 8 August 2010 (UTC) 5088:21:52, 8 August 2010 (UTC) 5083:and then an RfC via CENT. 5064:20:21, 8 August 2010 (UTC) 5042:16:52, 8 August 2010 (UTC) 5021:16:37, 8 August 2010 (UTC) 5010:16:07, 8 August 2010 (UTC) 4934:15:47, 8 August 2010 (UTC) 4924:15:27, 8 August 2010 (UTC) 4905:14:25, 8 August 2010 (UTC) 4871:13:29, 8 August 2010 (UTC) 4840:12:50, 8 August 2010 (UTC) 4818:11:09, 8 August 2010 (UTC) 4801:12:10, 6 August 2010 (UTC) 4786:02:01, 5 August 2010 (UTC) 4754:01:15, 5 August 2010 (UTC) 4731:00:41, 5 August 2010 (UTC) 4717:14:18, 4 August 2010 (UTC) 4662:14:25, 4 August 2010 (UTC) 4635:13:43, 4 August 2010 (UTC) 4601:12:08, 4 August 2010 (UTC) 4585:11:36, 4 August 2010 (UTC) 4566:05:35, 4 August 2010 (UTC) 4550:01:30, 4 August 2010 (UTC) 4519:17:24, 3 August 2010 (UTC) 4502:16:54, 3 August 2010 (UTC) 4480:16:41, 3 August 2010 (UTC) 4450:13:40, 3 August 2010 (UTC) 4417:19:34, 3 August 2010 (UTC) 4399:17:03, 3 August 2010 (UTC) 4370: 4327: 4323:The Man Who Sold the World 4316: 4266: 4255: 4206: 4110:15:46, 3 August 2010 (UTC) 4085:10:49, 3 August 2010 (UTC) 4067:10:39, 3 August 2010 (UTC) 4053:08:47, 3 August 2010 (UTC) 3871:23:47, 3 August 2010 (UTC) 3855:23:41, 3 August 2010 (UTC) 3692:site-wide style guidelines 3567:Tables with JAWS and MAGic 3478:Could someone tell me how 2602:Repetitive Title Injuries? 2596:10:27, 28 April 2010 (UTC) 2572:08:45, 28 April 2010 (UTC) 2547:Please note discussion of 2538:20:48, 25 April 2010 (UTC) 2455:10:59, 25 March 2010 (UTC) 2429:08:37, 25 March 2010 (UTC) 2398:23:20, 24 March 2010 (UTC) 2364:23:07, 24 March 2010 (UTC) 2258:14:25, 25 March 2010 (UTC) 2243:11:33, 25 March 2010 (UTC) 885:==Foo{{Anchors|Bar|Baz}}== 195:section there is a caveat: 133:might make more sense as 12558:04:16, 4 April 2011 (UTC) 12543:00:07, 4 April 2011 (UTC) 12513:23:41, 3 April 2011 (UTC) 12494:20:49, 3 April 2011 (UTC) 12464:03:02, 2 April 2011 (UTC) 12373:21:45, 1 April 2011 (UTC) 12335:American Idol (season 10) 12314:21:45, 1 April 2011 (UTC) 12288:19:52, 1 April 2011 (UTC) 12271:American Idol (season 10) 12265:19:19, 1 April 2011 (UTC) 12228:17:51, 1 April 2011 (UTC) 12194:16:38, 1 April 2011 (UTC) 12157:16:32, 1 April 2011 (UTC) 12123:17:03, 1 April 2011 (UTC) 12108:16:15, 1 April 2011 (UTC) 12082:15:42, 1 April 2011 (UTC) 12048:15:39, 1 April 2011 (UTC) 12018:01:43, 1 April 2011 (UTC) 11986:American Idol (season 10) 11782: 11768: 11754: 11740: 11726: 11721: 11718: 11715: 11712: 11250:With a different layout, 10050:Any objections? Regards, 9815:Section headers and links 9133:a table solution. Yours, 8016: 8011: 8006: 8003: 7995: 7990: 7987: 7923: 7915: 7907: 7902: 7899: 7803: 7800: 7797: 7252: 7244: 6881:text in any such case. -- 6728:. Now will you place the 6691:for the text removed and 5932:Kelly Rowland discography 5888:overwhelmed by the volume 5839:Changes to this guideline 5632:. Each pair requires one 5307:clipped denominator with 4330:Released: 4 November 1970 4320: 4269:Released: 4 November 1969 4259: 4199: 4192: 4187: 4182: 4177: 4172: 4167: 4162: 4157: 4152: 4147: 4033: 4030: 4027: 4024: 4021: 3903:16:53, 27 July 2010 (UTC) 3515:01:33, 30 June 2010 (UTC) 3492:19:02, 29 June 2010 (UTC) 3469:14:38, 29 June 2010 (UTC) 3403:14:20, 23 June 2010 (UTC) 3387:06:33, 23 June 2010 (UTC) 3359:01:26, 21 June 2010 (UTC) 3338:15:20, 20 June 2010 (UTC) 3321:15:19, 20 June 2010 (UTC) 3303:15:17, 20 June 2010 (UTC) 3280:15:14, 20 June 2010 (UTC) 3243:14:05, 15 June 2010 (UTC) 3211:13:59, 15 June 2010 (UTC) 3193:Speech and Sounds Manager 3181:02:15, 15 June 2010 (UTC) 3117:23:47, 20 June 2010 (UTC) 3081:00:57, 21 June 2010 (UTC) 3067:23:50, 20 June 2010 (UTC) 3046:05:38, 10 June 2010 (UTC) 2543:Species distribution maps 2511:10:13, 8 April 2010 (UTC) 2477:18:10, 7 April 2010 (UTC) 2329:22:54, 8 March 2010 (UTC) 2315:06:46, 1 March 2010 (UTC) 2284:12:46, 10 July 2010 (UTC) 1166:Also, in the archives of 185:Section headings and JAWS 10646:screen reader users are 10210:Following discussion at 9231:former touring musicians 8729:User:RexxS/Accessibility 8568:. This is good practice. 8303:User:RexxS/Accessibility 8193:accessibility guidelines 7793:Accessibility criterias 7729:element and the lack of 5989:at the top of this page. 5573:Accessibility initiative 4979:should be used sparingly 4703:User:RexxS/Accessibility 4608:NonVisual Desktop Access 4573:User:RexxS/Accessibility 3841:03:02, 10 May 2010 (UTC) 3719:05:43, 1 July 2010 (UTC) 3659:08:56, 1 July 2010 (UTC) 3622:03:46, 1 July 2010 (UTC) 3585:01:56, 1 July 2010 (UTC) 3545:00:15, 1 July 2010 (UTC) 2990:21:11, 9 June 2010 (UTC) 2972:16:29, 7 June 2010 (UTC) 2953:15:37, 7 June 2010 (UTC) 2921:15:37, 7 June 2010 (UTC) 2900:08:04, 7 June 2010 (UTC) 2882:06:57, 7 June 2010 (UTC) 2858:23:42, 6 June 2010 (UTC) 2814:16:29, 5 June 2010 (UTC) 2769:16:18, 5 June 2010 (UTC) 2749:16:05, 5 June 2010 (UTC) 2711:11:43, 5 June 2010 (UTC) 2691:08:41, 5 June 2010 (UTC) 2667:08:52, 18 May 2010 (UTC) 2463:General style guidelines 1532:http://netscape.aol.com/ 963:And since I think every 411:links in section headers 12388:<th scope="row": --> 11964:Should be fixed now. -- 11708:Difference of opinions 11423:(i.e. using <li: --> 10124:Tables section - a link 9701:Guidance on italic text 9491:Transparent backgrounds 9364:featured list candidacy 9033:I've also commented at 8880:photosensitive epilepsy 8795:photosensitive epilepsy 8750:Don't worry. I've just 8528:decides to support the 7895:Accessibility criteria 7836:Accessibility criterias 7473:20:43, 8 May 2010 (UTC) 7448:18:39, 8 May 2010 (UTC) 7414:00:10, 4 May 2010 (UTC) 7382:23:10, 3 May 2010 (UTC) 7366:22:01, 3 May 2010 (UTC) 6929:(Firefox page source:) 6134:While we're here, does 6104:M-28 (Michigan highway) 5684:For possible uses, see 5636:(dt) elements, and one 3818:11:38, 9 May 2010 (UTC) 3804:02:44, 9 May 2010 (UTC) 3783:18:17, 8 May 2010 (UTC) 3156:) or side comments (as 2640:21:47, 7 May 2010 (UTC) 2411:can't be "enforced" by 2308:WP:TFD#Template:Tooltip 2270:to the United States.-- 1120:footballbox collapsible 564:Take a look at the edit 12452:Accessible Data Tables 12337:has little to do with 10331:Template:Double-dagger 10085:Great! :-) It's done. 10048: 10038:Text - spelling errors 9564: 9175:User talk:Sir Edward V 9065:http://excel2wiki.net/ 9058:Having owned and used 8988:list article talk page 7938:Accessibility criteria 7775:Maybe this will help : 5700: 5134: 4990: 4974:Rowspans and colspans 4486:Thisisnotatest's edits 3763:|-style="display:none" 3755:|-style="display:none" 3433:from the item because 2488:MoS - Infobox headings 2419:have been resolved. -- 1815:indicated his approval 1712:needs to be modified. 1182:content is pertinant. 1086:I have followed up at 205: 11792:This is a side issue 11789:This is a side issue 11786:This is a side issue 10044: 9560: 9381:As for "2.", I added 8240:issue of data tables. 7428:WP:keyboard shortcuts 7372:more details? Yours, 6923:(Opera page source:) 5681: 5630:advertising a product 5123: 4963: 4209:Released: 1 June 1967 4130:Peak chart positions 4017:Peak chart positions 3725:Hidden rows in tables 3376:screen readers work. 3135:Previous discussion: 2679:...</timeline: --> 2645:Captions for line art 2036:I've boldly added a " 1949:There's a dispute at 1656:Walsall Football Club 1567:The Print Preview of 1177:I've also discovered 197: 46:of past discussions. 11747:Doubts Andy's claim 9532:User:Blackbackground 9508:in the first place ? 9373:The use of color in 9319:tutorial talk page. 8946:An editor created a 8904:Yes, precisely. :-) 8112:The problem is that 6967:are read by JAWS. -- 6858:I'd be in favour of 6057:becomes part of the 5621:Response to Dodoïste 4536:Just found out that 3889:A quick note on the 3499:I'll respond at the 3251:Template:Chinesetext 2415:until all issues in 2320:Note: discussion at 2266:, has at least some 1945:Spaces with ref tags 1853:No objections here. 967:has a corresponding 12361:internal guidelines 12167:the six GA criteria 11709: 9717:But in the section 9475:to this guideline. 8884:Extinct in the Wild 8799:Extinct in the Wild 8727:the first table in 7991:Number of criteria 7984: 7903:Number of criteria 7896: 7794: 6878:List of poker hands 6840:List of poker hands 6456:List of poker hands 4972:As a rule of thumb, 3912:{|class="wikitable" 2734:Horizontal timeline 869:You gotta read the 11707: 10325:Ok - I've amended 10206:Accessible symbols 9513:On the other hand 8888:Endangered species 8803:Endangered species 8753: 7982: 7944:Number of criteria 7894: 7792: 6497:Yes they are, see 6368:Non standard ASCII 5984:Under construction 5777:.css stylesheet... 5226:Template talk:Frac 4389:. Thanks again, -- 3750:and text browsers. 3455:speech synthesizer 3427:speech synthesizer 1976:Common<ref: --> 1577:Netscape Navigator 1536:Netscape Navigator 1469:Netscape Navigator 1433:Netscape Navigator 940:, something like: 324:– Works for me! — 11796: 11795: 11186:Template:Flatlist 10772:even relevant? 10238:. All the best, 10008: 9961: 9463: 9171:User:Sir Edward V 9153: 8751: 8473:Images with links 8213:common experience 8024: 8023: 7931: 7930: 7819: 7818: 7124:OK, fair enough. 6931:1) ♥ 2) ♥ or 3) ♥ 6925:1) ♥ 2) ♥ or 3) ♥ 6685: 6293: 6211:To be changed to 6185:Following on from 6156:Template:MIinttop 6044: 6024: 5955: 5250: 5249: 4826:. Statement that 4374: 4373: 4143: 4038: 4037: 3926:rowspan="2"| Year 3740:...</span: --> 3385: 3371:. I'm curious as 3278: 2856: 2678:<timeline: --> 2153:Furthermore, see 2139: 1669: 1153:Internet Explorer 1078: 1037: 919: 491: 229:Happy Editing! — 107: 106: 58: 57: 52:current talk page 12595: 12588: 12585: 12579: 12576: 12535: 12533: 12529: 12217: 12213: 12208: 12203: 12149: 12147: 12143: 12115:The Rambling Man 12106: 12097: 12093: 12074:The Rambling Man 12046: 12037: 12033: 12023:Projects do not 12010: 12008: 12004: 11996: 11992: 11934: 11925: 11921: 11890: 11881: 11877: 11850: 11841: 11837: 11710: 11706: 11684: 11675: 11671: 11643: 11634: 11630: 11616: 11607: 11603: 11467:The Rambling Man 11443: 11434: 11430: 11402: 11396: 11374:British Columbia 11366: 11365: 11360: 11354: 11339:The Rambling Man 11307: 11301: 11285:The Rambling Man 11261:"potential". XD 11259: 11253: 11243: 11217:The Rambling Man 11214: 11208: 11199: 11193: 11153:The Rambling Man 11115: 11109: 11105: 11099: 11095: 11089: 11085: 11079: 11061: 11055: 11037: 11031: 10977: 10971: 10955:The Rambling Man 10936:Knowledge:Graphs 10901: 10846: 10842: 10841: 10796: 10774:The Rambling Man 10767: 10761: 10703:The Rambling Man 10663: 10632:The Rambling Man 10624: 10618: 10582: 10560:The Rambling Man 10525:The Rambling Man 10500: 10482:The Rambling Man 10451:The Rambling Man 10422: 10416: 10401:The Rambling Man 10366:The Rambling Man 10313:The Rambling Man 10276: 10270: 10240:The Rambling Man 10233: 10227: 10223: 10217: 10187: 10183: 10182: 10146:The Rambling Man 10106:The Rambling Man 10078: 10006: 9956: 9928: 9912: 9864: 9858: 9854: 9848: 9773: 9659: 9638:The Rambling Man 9629: 9608:The Rambling Man 9594: 9572:The Rambling Man 9464: 9458: 9457: 9323:. Kind regards, 9147: 8749:<cynical: --> 8633: 8629: 8610: 8603: 8531: 7985: 7981: 7897: 7893: 7859: 7855: 7795: 7791: 7747: 7743: 7739: 7732: 7728: 7718: 7717: 7716: 7709: 7705: 7636:fr:user talk:Lgd 7530: 7399: 7393: 7301: 7294: 7276: 7255: 7254: 7247: 7246: 7232: 7133: 7105: 7099: 7095: 7089: 7085: 7079: 7070: 6990: 6962: 6958: 6951: 6947: 6932: 6926: 6920: 6805: 6731: 6727: 6723: 6719: 6679: 6588: 6587: 6584: 6576: 6575: 6572: 6565: 6547: 6542: 6536: 6476: 6468: 6461: 6427: 6381: 6380: 6377: 6294: 6291: 6286: 6137: 6127: 6124: 6117: 6112: 6101: 6045: 6042: 6038: 6025: 6022: 6018: 5988: 5982: 5956: 5953: 5949: 5778: 5697: 5691: 5671: 5665: 5615:Response to Jack 5570: 5520:. <aside: --> 5501:fr:User:Dodoïste 5399: 5389: 5322: 5316: 5310: 5291: 5290: 5286: 5260: 5246: 5245: 5241: 5232: 5231: 5223: 5217: 5212: 5206: 4714: 4563: 4140:sales thresholds 4137: 4121: 4120: 4008: 4007: 3997: 3993: 3914: 3801: 3764: 3756: 3741: 3656: 3582: 3512: 3466: 3400: 3384: 3381: 3356: 3330: 3318: 3295: 3277: 3274: 3264: 3258: 3240: 3208: 3166: 3155: 3151: 3147: 3059: 2897: 2855: 2853: 2846: 2839: 2803: 2797: 2784: 2780: 2766: 2738: 2732: 2728: 2722: 2717:WP:ALT#timelines 2708: 2680: 2586: 2582: 2581: 2570: 2561: 2557: 2516:MoS naming style 2509: 2500: 2496: 2482:Infobox headings 2453: 2444: 2440: 2396: 2387: 2383: 2362: 2353: 2349: 2296:Template:Tooltip 2209: 2166: 2133: 2043: 2010: 1981:Two</ref: --> 1977:One</ref: --> 1928: 1862: 1759:I too have been 1721: 1653: 1471:(available from 1385: 1331: 1293: 1247: 1158:I also have the 1144:I installed the 1124: 1118: 1111:outdated advice? 1079: 1073: 1072: 1038: 1032: 1031: 999: 995: 988: 984: 979: 975: 970: 966: 956: 946: 920: 914: 913: 898: 894: 890: 886: 882: 878: 872: 857: 838:the history page 824: 745: 744:{{Anchor|thumb}} 740: 739:== Thumbnails == 723: 694: 673: 649: 633: 613: 582: 550: 514: 506: 492: 486: 485: 460: 439: 417:October 23, 2009 367: 343: 323: 319: 318: 280: 176: 85: 60: 59: 37: 36: 30: 12603: 12602: 12598: 12597: 12596: 12594: 12593: 12592: 12591: 12586: 12582: 12577: 12573: 12531: 12527: 12525: 12415:where possible; 12321: 12214: 12210: 12205: 12200: 12177:"requirements". 12145: 12141: 12139: 12095: 12089: 12088: 12035: 12029: 12028: 12006: 12002: 12000: 11994: 11990: 11982: 11943: 11923: 11917: 11916: 11879: 11873: 11872: 11839: 11833: 11832: 11673: 11667: 11666: 11632: 11626: 11625: 11605: 11599: 11598: 11564: 11548: 11532: 11513: 11432: 11426: 11425: 11400: 11394: 11363: 11358: 11352: 11305: 11299: 11257: 11251: 11241: 11212: 11206: 11197: 11191: 11188: 11148: 11113: 11107: 11103: 11097: 11093: 11087: 11083: 11077: 11059: 11053: 11045: 11035: 11029: 11000: 10975: 10969: 10899: 10871: 10839: 10837: 10794: 10765: 10759: 10752: 10661: 10622: 10616: 10613: 10611:Other languages 10580: 10543: 10541:Image placement 10521:contract bridge 10429:Template:Spades 10420: 10414: 10327:Template:Dagger 10311:designation). 10231: 10225: 10221: 10215: 10208: 10180: 10178: 10126: 10076: 10040: 9979: 9943: 9926: 9910: 9862: 9856: 9852: 9846: 9817: 9771: 9703: 9657: 9627: 9592: 9556: 9493: 9452: 9446: 9439: 9356: 9282: 9060:Microsoft Excel 8944: 8631: 8627: 8608: 8601: 8566:in that context 8529: 8475: 8424: 7857: 7853: 7753:your screenshot 7745: 7741: 7737: 7730: 7726: 7723:Zachary Bennett 7714: 7707: 7703: 7540: 7528: 7515: 7397: 7391: 7349: 7328: 7299: 7292: 7274: 7230: 7131: 7103: 7097: 7093: 7087: 7083: 7077: 7068: 6988: 6957:♥</abbr: --> 6955: 6946:♥</span: --> 6944: 6930: 6924: 6918: 6876:As the article 6813:There are also 6803: 6729: 6725: 6721: 6720:is deprecated. 6717: 6701: 6694: 6590: 6585: 6582: 6581: 6578: 6573: 6570: 6569: 6563: 6546:♠</abbr: --> 6544: 6540: 6534: 6472: 6464: 6459: 6425: 6378: 6375: 6374: 6370: 6290: 6282: 6273: 6254: 6228:transliteration 6196:transliteration 6190: 6135: 6123: 6120: 6115: 6110: 6107: 6099: 6095: 6041: 6034: 6021: 6014: 5986: 5980: 5952: 5945: 5841: 5812:bold</b: --> 5772: 5695: 5689: 5669: 5663: 5568: 5449:definition list 5410: 5397: 5383: 5314: 5308: 5288: 5284: 5283: 5253: 5243: 5239: 5238: 5221: 5215: 5210: 5204: 5197: 4712: 4561: 4435: 3995: 3916: 3911: 3887: 3799: 3762: 3754: 3738: 3727: 3716: 3680: 3654: 3580: 3510: 3476: 3464: 3419: 3398: 3383: 3379: 3354: 3328: 3316: 3293: 3276: 3272: 3262: 3256: 3253: 3238: 3225:emphasised text 3206: 3164: 3154:<strong: --> 3153: 3149: 3145: 3131: 3057: 2929: 2895: 2865: 2849: 2842: 2840: 2834:which involves 2828: 2811: 2801: 2795: 2782: 2778: 2764: 2746: 2736: 2730: 2726: 2720: 2706: 2688: 2677: 2674: 2647: 2604: 2579: 2577: 2559: 2553: 2552: 2545: 2518: 2498: 2492: 2491: 2484: 2465: 2442: 2436: 2435: 2385: 2379: 2378: 2371: 2351: 2345: 2344: 2337: 2292: 2207: 2164: 2088: 2041: 2008: 1947: 1926: 1923: 1900: 1886: 1860: 1827: 1789: 1779: 1719: 1710:Template:Navbox 1573:Mozilla Firefox 1477:Mozilla Firefox 1461: 1425:Mozilla Firefox 1383: 1355: 1329: 1312: 1291: 1270: 1245: 1201: 1151:I normally use 1122: 1116: 1113: 1067: 1065: 1059: 1048: 1026: 1024: 1018: 997: 993: 986: 982: 977: 973: 968: 964: 954: 944: 934: 908: 906: 900: 896: 892: 888: 884: 880: 876: 870: 845: 812: 743: 738: 728:Template:Anchor 721: 713: 692: 661: 647: 631: 611: 570: 538: 510: 502: 480: 478: 472: 458: 427: 413: 390: 365: 339: 326:141.156.161.245 316: 314: 289:141.156.161.245 278: 250: 232:141.156.161.245 187: 174: 112: 81: 34: 26: 25: 24: 12: 11: 5: 12601: 12590: 12589: 12580: 12570: 12569: 12568: 12567: 12566: 12565: 12564: 12563: 12562: 12561: 12560: 12482: 12475: 12474: 12473: 12444: 12440: 12437: 12434: 12431: 12424: 12423: 12422: 12419: 12416: 12414: 12409: 12407: 12399: 12391: 12389: 12320: 12317: 12299: 12298: 12297: 12296: 12295: 12294: 12293: 12292: 12291: 12290: 12249: 12235: 12234: 12233: 12232: 12231: 12230: 12178: 12174: 12170: 12160: 12159: 12132: 12131: 12130: 12129: 12128: 12127: 12126: 12125: 12068:did for us at 11981: 11978: 11977: 11976: 11942: 11939: 11909: 11908: 11907: 11906: 11905: 11904: 11903: 11902: 11901: 11900: 11899: 11898: 11897: 11896: 11895: 11894: 11806: 11805: 11804: 11803: 11802: 11801: 11800: 11799: 11798: 11797: 11794: 11793: 11790: 11787: 11784: 11780: 11779: 11776: 11773: 11770: 11766: 11765: 11762: 11759: 11756: 11752: 11751: 11748: 11745: 11742: 11738: 11737: 11734: 11731: 11728: 11724: 11723: 11720: 11717: 11714: 11695: 11694: 11693: 11692: 11691: 11690: 11689: 11688: 11622: 11621: 11620: 11563: 11562: 11559: 11556: 11549: 11547: 11546: 11543: 11540: 11533: 11531: 11530: 11527: 11524: 11521: 11514: 11512: 11511: 11508: 11505: 11502: 11499: 11496: 11489: 11488: 11487: 11486: 11485: 11458: 11457: 11456: 11455: 11454: 11453: 11452: 11451: 11450: 11449: 11448: 11447: 11417: 11416: 11415: 11391: 11390: 11389: 11382: 11376: 11368: 11187: 11184: 11183: 11182: 11168:bugzilla:19906 11147: 11144: 11143: 11142: 11141: 11140: 11139: 11138: 11137: 11136: 11135: 11134: 11133: 11132: 11131: 11130: 11129: 11128: 11043: 11012: 10998: 10931: 10930: 10929: 10928: 10913: 10907: 10906: 10870: 10867: 10866: 10865: 10864: 10863: 10862: 10861: 10860: 10859: 10820: 10751: 10748: 10747: 10746: 10745: 10744: 10743: 10742: 10741: 10740: 10718: 10717: 10716: 10715: 10714: 10713: 10693: 10692: 10691: 10690: 10669: 10668: 10612: 10609: 10608: 10607: 10606: 10605: 10555: 10554: 10553: 10552: 10542: 10539: 10538: 10537: 10536: 10535: 10478: 10477: 10476: 10475: 10474: 10473: 10472: 10471: 10470: 10469: 10468: 10467: 10466: 10465: 10464: 10463: 10462: 10461: 10305: 10207: 10204: 10203: 10202: 10201: 10200: 10161: 10142: 10141: 10140: 10139: 10125: 10122: 10121: 10120: 10119: 10118: 10117: 10116: 10039: 10036: 10035: 10034: 10033: 10032: 10017: 10009: 9977: 9976: 9975: 9962: 9942: 9939: 9938: 9937: 9936: 9935: 9934: 9933: 9842: 9841: 9829: 9828: 9816: 9813: 9812: 9811: 9810: 9809: 9808: 9807: 9727: 9726: 9715: 9714: 9702: 9699: 9673: 9672: 9671: 9670: 9669: 9668: 9667: 9666: 9665: 9664: 9555: 9552: 9551: 9550: 9523: 9522: 9510: 9509: 9492: 9489: 9488: 9487: 9438: 9435: 9434: 9433: 9432: 9431: 9379: 9378: 9371: 9355: 9352: 9351: 9350: 9316: 9315: 9281: 9278: 9262: 9261: 9227: 9226: 9225: 9224: 9223: 9222: 9221: 9220: 9219: 9218: 9145: 9112: 9111: 9110: 9109: 9108: 9056: 9055: 9054: 9053: 9052: 9051: 9050: 8983: 8943: 8940: 8939: 8938: 8937: 8936: 8935: 8934: 8933: 8932: 8931: 8930: 8871: 8870: 8869: 8868: 8867: 8866: 8865: 8864: 8791: 8788: 8787: 8786: 8785: 8784: 8783: 8782: 8781: 8780: 8779: 8778: 8777: 8776: 8775: 8774: 8773: 8772: 8771: 8770: 8755: 8724: 8705: 8664: 8661: 8657: 8653: 8605: 8594: 8572: 8569: 8562: 8561: 8560: 8549: 8548: 8547: 8546: 8545: 8544: 8474: 8471: 8470: 8469: 8423: 8420: 8419: 8418: 8417: 8416: 8415: 8414: 8413: 8412: 8411: 8410: 8409: 8408: 8407: 8406: 8405: 8404: 8403: 8402: 8401: 8400: 8399: 8398: 8397: 8396: 8395: 8394: 8380: 8299: 8286: 8273: 8256: 8249: 8241: 8237: 8230: 8196: 8169: 8165: 8162: 8090: 8086: 8075: 8053:user:Eubulides 8048: 8044: 8022: 8021: 8018: 8014: 8013: 8009: 8008: 8005: 8001: 8000: 7997: 7993: 7992: 7989: 7980: 7979: 7963: 7960: 7957: 7954: 7951: 7948: 7945: 7942: 7939: 7936: 7929: 7928: 7925: 7921: 7920: 7917: 7913: 7912: 7909: 7905: 7904: 7901: 7892: 7891: 7886: 7885: 7884: 7883: 7882: 7881: 7880: 7879: 7878: 7877: 7876: 7875: 7861: 7849: 7847: 7845: 7843: 7841: 7839: 7837: 7835: 7833: 7817: 7816: 7813: 7810: 7806: 7805: 7802: 7799: 7790: 7789: 7788: 7787: 7786: 7785: 7784: 7783: 7782: 7781: 7780: 7779: 7776: 7759: 7758: 7757: 7749: 7734: 7719: 7697: 7696: 7684: 7683: 7682: 7681: 7680: 7679: 7678: 7677: 7655: 7654: 7653: 7652: 7651: 7650: 7631: 7619: 7618: 7617: 7616: 7595: 7594: 7539: 7536: 7514: 7511: 7510: 7509: 7508: 7507: 7506: 7505: 7504: 7503: 7502: 7501: 7460: 7455:For example: 7453: 7419: 7418: 7417: 7416: 7401: 7385: 7384: 7348: 7345: 7327: 7324: 7323: 7322: 7321: 7320: 7319: 7318: 7296: 7239: 7235: 7227: 7224: 7223: 7222: 7221: 7220: 7219: 7218: 7217: 7216: 7215: 7214: 7213: 7212: 7198: 7039: 7038: 7023: 7022: 7021: 7020: 7019: 7018: 7017: 7016: 7015: 7014: 7013: 7012: 7011: 7010: 7009: 6965: 6964: 6963: 6952: 6935: 6934: 6933: 6927: 6921: 6836:strong grounds 6794:Template:Cards 6786: 6785: 6784: 6783: 6782: 6781: 6780: 6779: 6778: 6777: 6776: 6775: 6774: 6773: 6772: 6771: 6770: 6769: 6768: 6767: 6766: 6765: 6764: 6763: 6699: 6692: 6677: 6579: 6567: 6517: 6449: 6448: 6433: 6432: 6415: 6414: 6400:screen readers 6369: 6366: 6365: 6364: 6350: 6349: 6348: 6343: 6338: 6330: 6315: 6314: 6313: 6308: 6272: 6269: 6268: 6267: 6252: 6248: 6247: 6246: 6245: 6231: 6209: 6208: 6189: 6183: 6182: 6181: 6180: 6179: 6164: 6121: 6094: 6091: 6090: 6089: 6088: 6087: 6086: 6085: 6084: 6083: 6082: 6081: 6080: 6079: 6078: 6077: 6030: 5990: 5968: 5967: 5966: 5965: 5964: 5963: 5962: 5961: 5921: 5920: 5919: 5918: 5917: 5916: 5880: 5879: 5840: 5837: 5836: 5835: 5834: 5833: 5832: 5831: 5830: 5829: 5828: 5827: 5826: 5825: 5800: 5799: 5798: 5731: 5727: 5718: 5717: 5716: 5715: 5701: 5698:to shorten it. 5679: 5676: 5673: 5653: 5652: 5622: 5619: 5616: 5612: 5611: 5610: 5609: 5608: 5607: 5606: 5605: 5589: 5577: 5561: 5554: 5546: 5543: 5536: 5523: 5505: 5492: 5491: 5490: 5489: 5474: 5459: 5458: 5409: 5406: 5405: 5404: 5379: 5378: 5377: 5376: 5375: 5374: 5373: 5372: 5259:</span: --> 5258:2</sub: --> 5256:1</sup: --> 5248: 5247: 5236: 5196: 5193: 5192: 5191: 5173: 5172: 5158: 5157: 5122: 5121: 5120: 5119: 5118: 5117: 5116: 5115: 5098: 5094: 5080: 5071: 5070: 5069: 5068: 5067: 5066: 5047: 5046: 5045: 5044: 5024: 5023: 4970:under review. 4965:Images should 4951: 4950: 4949: 4948: 4947: 4946: 4945: 4944: 4943: 4942: 4941: 4940: 4939: 4938: 4937: 4936: 4911: 4858: 4777: 4776: 4775: 4774: 4773: 4772: 4771: 4770: 4769: 4768: 4767: 4766: 4765: 4764: 4763: 4762: 4761: 4760: 4759: 4758: 4757: 4756: 4681: 4680: 4679: 4678: 4677: 4676: 4675: 4674: 4673: 4672: 4671: 4670: 4669: 4668: 4667: 4666: 4665: 4664: 4650: 4615: 4534: 4530: 4527: 4524: 4467: 4464:screen readers 4460: 4434: 4431: 4430: 4429: 4428: 4427: 4426: 4425: 4424: 4423: 4422: 4421: 4420: 4419: 4372: 4371: 4369: 4366: 4363: 4360: 4357: 4354: 4351: 4348: 4345: 4342: 4339: 4338: 4337: 4334: 4333:Label: Mercury 4331: 4326: 4318: 4317: 4315: 4312: 4309: 4306: 4303: 4300: 4297: 4294: 4291: 4288: 4285: 4284: 4283: 4280: 4270: 4265: 4257: 4256: 4254: 4251: 4248: 4245: 4242: 4239: 4236: 4233: 4230: 4227: 4224: 4223: 4222: 4216: 4210: 4205: 4197: 4196: 4191: 4186: 4181: 4176: 4171: 4166: 4161: 4156: 4151: 4145: 4144: 4136: 4134:Certifications 4131: 4128: 4127:Album details 4125: 4119: 4118: 4117: 4116: 4115: 4114: 4113: 4112: 4094: 4040: 4039: 4036: 4035: 4032: 4029: 4026: 4023: 4019: 4018: 4015: 4014:Album details 4012: 4004: 4003: 3999: 3998: 3992: 3991: 3988: 3987: 3980: 3979: 3972: 3971: 3964: 3963: 3956: 3955: 3948: 3947: 3944: 3943: 3936: 3935: 3928: 3927: 3920: 3919: 3915: 3913: 3909: 3886: 3883: 3882: 3881: 3880: 3879: 3878: 3877: 3876: 3875: 3874: 3873: 3759: 3758: 3751: 3748:screen readers 3726: 3723: 3722: 3721: 3714: 3700:Moonriddengirl 3679: 3673: 3672: 3671: 3670: 3669: 3668: 3667: 3666: 3665: 3664: 3663: 3662: 3661: 3633: 3632: 3631: 3630: 3629: 3628: 3627: 3626: 3625: 3624: 3610: 3594: 3593: 3592: 3591: 3590: 3589: 3588: 3587: 3552: 3551: 3550: 3549: 3548: 3547: 3520: 3519: 3518: 3517: 3475: 3472: 3418: 3415: 3414: 3413: 3412: 3411: 3410: 3409: 3408: 3407: 3406: 3405: 3377: 3306: 3305: 3270: 3252: 3249: 3248: 3247: 3246: 3245: 3226: 3216: 3214: 3213: 3169:Damian Yerrick 3165:<small: --> 3141: 3140: 3130: 3127: 3126: 3125: 3124: 3123: 3122: 3121: 3120: 3119: 3094: 3093: 3092: 3091: 3090: 3089: 3088: 3087: 3086: 3085: 3084: 3083: 3049: 3048: 3030: 2995: 2994: 2993: 2992: 2975: 2974: 2928: 2925: 2924: 2923: 2903: 2902: 2864: 2861: 2827: 2824: 2823: 2822: 2821: 2820: 2819: 2818: 2817: 2816: 2809: 2776: 2775: 2774: 2773: 2772: 2771: 2744: 2697:Apparently not 2686: 2673: 2670: 2646: 2643: 2624: 2623: 2615: 2603: 2600: 2599: 2598: 2544: 2541: 2517: 2514: 2486:Discussion at 2483: 2480: 2464: 2461: 2460: 2459: 2458: 2457: 2370: 2367: 2336: 2333: 2332: 2331: 2294:I have listed 2291: 2288: 2287: 2286: 2272:Damian Yerrick 2260: 2223: 2222: 2221: 2220: 2219: 2218: 2217: 2216: 2215: 2214: 2176: 2175: 2174: 2173: 2172: 2171: 2146: 2145: 2144: 2143: 2123: 2122: 2087: 2084: 2083: 2082: 2060: 2059: 2058: 2057: 2056: 2016: 2015: 1983: 1982: 1978: 1970: 1969: 1966: 1946: 1943: 1927:font-size: 90% 1922: 1919: 1899: 1896: 1895: 1894: 1893: 1892: 1891: 1890: 1880: 1848: 1847: 1821: 1800:, has already 1788: 1785: 1784: 1783: 1773: 1737: 1736: 1735: 1734: 1733: 1732: 1731: 1730: 1729: 1728: 1727: 1726: 1686: 1685: 1684: 1683: 1682: 1681: 1680: 1679: 1678: 1677: 1676: 1675: 1674: 1673: 1672: 1671: 1670: 1565: 1564: 1563: 1562: 1561: 1473:OldVersion.com 1455: 1397: 1396: 1395: 1394: 1393: 1392: 1391: 1390: 1349: 1323: 1322: 1321: 1320: 1319: 1318: 1317: 1316: 1306: 1264: 1235: 1234: 1233: 1195: 1164: 1163: 1156: 1149: 1112: 1106: 1105: 1104: 1061: 1047: 1044: 1043: 1042: 1020: 958: 957: 950:such that any 948: 947: 933: 930: 929: 928: 927: 926: 925: 924: 902: 842: 834: 809: 798: 797: 747: 746: 741: 725: 724: 712: 709: 708: 707: 706: 705: 704: 703: 702: 701: 700: 699: 658: 597: 596: 595: 594: 593: 592: 567: 560: 535: 498: 497: 496: 474: 459:Gadget850 (Ed) 424: 412: 409: 389: 386: 385: 384: 383: 382: 381: 380: 379: 378: 377: 376: 375: 374: 373: 372: 266: 265: 246: 186: 183: 182: 181: 149:Thisisnotatest 111: 108: 105: 104: 99: 96: 91: 86: 79: 74: 69: 66: 56: 55: 38: 15: 9: 6: 4: 3: 2: 12600: 12584: 12575: 12571: 12559: 12555: 12551: 12546: 12545: 12544: 12541: 12540: 12537: 12536: 12521: 12516: 12515: 12514: 12510: 12506: 12503:chose." ;) -- 12502: 12501:une meilleure 12497: 12496: 12495: 12491: 12487: 12483: 12480: 12476: 12470: 12469: 12467: 12466: 12465: 12461: 12457: 12453: 12449: 12445: 12441: 12438: 12435: 12432: 12429: 12425: 12420: 12417: 12413:! scope="row" 12412: 12410: 12406:! scope="col" 12405: 12403: 12402: 12400: 12396: 12392: 12387: 12385: 12381: 12377: 12376: 12375: 12374: 12370: 12366: 12362: 12358: 12353: 12351: 12347: 12343: 12340: 12336: 12332: 12328: 12326: 12316: 12315: 12311: 12307: 12303: 12289: 12285: 12281: 12276: 12272: 12268: 12267: 12266: 12262: 12258: 12254: 12250: 12247: 12243: 12242: 12241: 12240: 12239: 12238: 12237: 12236: 12229: 12225: 12221: 12216: 12212: 12207: 12202: 12197: 12196: 12195: 12191: 12187: 12183: 12179: 12175: 12171: 12168: 12164: 12163: 12162: 12161: 12158: 12155: 12154: 12151: 12150: 12134: 12133: 12124: 12120: 12116: 12111: 12110: 12109: 12105: 12101: 12096:Pigsonthewing 12092: 12085: 12084: 12083: 12079: 12075: 12071: 12067: 12063: 12059: 12055: 12051: 12050: 12049: 12045: 12041: 12036:Pigsonthewing 12032: 12026: 12022: 12021: 12020: 12019: 12016: 12015: 12012: 12011: 11987: 11975: 11971: 11967: 11963: 11962: 11961: 11960: 11956: 11952: 11948: 11938: 11937: 11933: 11929: 11924:Pigsonthewing 11920: 11914: 11893: 11889: 11885: 11880:Pigsonthewing 11876: 11870: 11869: 11868: 11864: 11860: 11855: 11854: 11853: 11849: 11845: 11840:Pigsonthewing 11836: 11830: 11829: 11828: 11824: 11820: 11816: 11815: 11814: 11813: 11812: 11811: 11810: 11809: 11808: 11807: 11791: 11788: 11785: 11781: 11777: 11774: 11771: 11767: 11763: 11760: 11757: 11753: 11749: 11746: 11743: 11739: 11735: 11732: 11729: 11725: 11711: 11705: 11704: 11703: 11702: 11701: 11700: 11699: 11698: 11697: 11696: 11687: 11683: 11679: 11674:Pigsonthewing 11670: 11663: 11662: 11661: 11657: 11653: 11648: 11647: 11646: 11642: 11638: 11633:Pigsonthewing 11629: 11623: 11619: 11615: 11611: 11606:Pigsonthewing 11602: 11596: 11595: 11594: 11590: 11586: 11581: 11580: 11579: 11575: 11571: 11566: 11565: 11560: 11557: 11554: 11551: 11550: 11544: 11541: 11538: 11535: 11534: 11528: 11525: 11522: 11519: 11516: 11515: 11509: 11506: 11503: 11500: 11497: 11494: 11491: 11490: 11483: 11482: 11479: 11478: 11477: 11476: 11472: 11468: 11464: 11446: 11442: 11438: 11433:Pigsonthewing 11429: 11422: 11418: 11414: 11410: 11406: 11399: 11392: 11387: 11383: 11381: 11377: 11375: 11371: 11370: 11369: 11357: 11350: 11349: 11348: 11344: 11340: 11336: 11335: 11334: 11330: 11326: 11321: 11320: 11319: 11315: 11311: 11304: 11296: 11295: 11294: 11290: 11286: 11282: 11278: 11274: 11273: 11272: 11268: 11264: 11256: 11249: 11248: 11247: 11244: 11239: 11238: 11233: 11229: 11228: 11227: 11226: 11222: 11218: 11211: 11203: 11196: 11181: 11177: 11173: 11169: 11165: 11164: 11163: 11162: 11158: 11154: 11127: 11123: 11119: 11112: 11102: 11092: 11082: 11075: 11074: 11073: 11069: 11065: 11058: 11052:I just found 11051: 11050: 11049: 11046: 11041: 11034: 11027: 11026: 11025: 11021: 11017: 11013: 11010: 11006: 11005: 11004: 11001: 10996: 10991: 10990: 10989: 10985: 10981: 10974: 10966: 10965: 10964: 10960: 10956: 10951: 10950: 10949: 10945: 10941: 10937: 10933: 10932: 10927: 10923: 10919: 10914: 10911: 10910: 10909: 10908: 10905: 10902: 10897: 10896: 10891: 10890: 10889: 10888: 10884: 10880: 10876: 10858: 10854: 10850: 10845: 10836: 10835: 10834: 10830: 10826: 10821: 10817: 10816: 10815: 10811: 10807: 10802: 10801: 10800: 10797: 10792: 10791: 10786: 10785: 10784: 10783: 10779: 10775: 10771: 10764: 10757: 10739: 10735: 10731: 10726: 10725: 10724: 10723: 10722: 10721: 10720: 10719: 10712: 10708: 10704: 10699: 10698: 10697: 10696: 10695: 10694: 10689: 10685: 10681: 10677: 10673: 10672: 10671: 10670: 10667: 10664: 10659: 10658: 10653: 10649: 10644: 10643: 10642: 10641: 10637: 10633: 10628: 10621: 10604: 10600: 10596: 10592: 10588: 10587: 10586: 10583: 10578: 10577: 10572: 10571: 10570: 10569: 10565: 10561: 10550: 10549: 10548: 10547: 10546: 10534: 10530: 10526: 10522: 10518: 10514: 10513: 10512: 10508: 10504: 10499: 10494: 10493: 10492: 10491: 10487: 10483: 10460: 10456: 10452: 10448: 10447: 10446: 10442: 10438: 10434: 10430: 10426: 10419: 10412: 10411: 10410: 10406: 10402: 10398: 10394: 10393: 10392: 10388: 10385: 10382: 10377: 10376: 10375: 10371: 10367: 10362: 10361: 10360: 10356: 10353: 10350: 10346: 10345: 10344: 10340: 10336: 10332: 10328: 10324: 10323: 10322: 10318: 10314: 10310: 10306: 10304: 10300: 10297: 10294: 10290: 10289: 10288: 10284: 10280: 10275: 10269: 10264: 10263:technique F26 10260: 10256: 10252: 10251: 10250: 10249: 10245: 10241: 10237: 10230: 10229:double-dagger 10220: 10213: 10199: 10195: 10191: 10186: 10177: 10176: 10175: 10171: 10167: 10162: 10158: 10157: 10156: 10155: 10151: 10147: 10137: 10136: 10135: 10134: 10133: 10131: 10115: 10111: 10107: 10102: 10098: 10097: 10096: 10092: 10088: 10084: 10083: 10082: 10079: 10074: 10073: 10068: 10064: 10063: 10062: 10061: 10057: 10053: 10047: 10043: 10031: 10027: 10023: 10018: 10015: 10011: 10010: 10004: 10003: 10000: 9995: 9994: 9993: 9992: 9988: 9984: 9973: 9969: 9965: 9964: 9963: 9959: 9954: 9953: 9950: 9932: 9929: 9924: 9923: 9918: 9917: 9916: 9913: 9908: 9907: 9902: 9901: 9900: 9896: 9892: 9888: 9887: 9886: 9885: 9881: 9877: 9873: 9868: 9861: 9851: 9839: 9838: 9837: 9835: 9826: 9825: 9824: 9822: 9806: 9802: 9798: 9794: 9793: 9792: 9788: 9784: 9779: 9778: 9777: 9774: 9769: 9768: 9762: 9761: 9760: 9759: 9755: 9751: 9747: 9743: 9738: 9736: 9732: 9724: 9723: 9722: 9721:, we advise: 9720: 9712: 9711: 9710: 9708: 9698: 9697: 9693: 9689: 9684: 9682: 9676: 9663: 9660: 9655: 9654: 9649: 9648: 9647: 9643: 9639: 9635: 9634: 9633: 9630: 9625: 9624: 9619: 9618: 9617: 9613: 9609: 9604: 9600: 9599: 9598: 9595: 9590: 9589: 9584: 9583: 9582: 9581: 9577: 9573: 9569: 9563: 9559: 9549: 9545: 9541: 9536: 9535: 9534: 9533: 9527: 9520: 9518: 9512: 9511: 9507: 9503: 9502: 9501: 9499: 9486: 9482: 9478: 9474: 9470: 9469: 9468: 9467: 9461: 9455: 9451: 9450: 9444: 9430: 9426: 9422: 9418: 9417: 9416: 9412: 9408: 9404: 9400: 9399: 9398: 9397: 9393: 9389: 9384: 9376: 9372: 9369: 9368: 9367: 9365: 9361: 9349: 9345: 9341: 9337: 9336: 9335: 9334: 9330: 9326: 9322: 9314: 9310: 9306: 9302: 9301: 9300: 9299: 9295: 9291: 9287: 9277: 9276: 9272: 9268: 9260: 9256: 9252: 9247: 9246: 9245: 9244: 9240: 9236: 9232: 9217: 9213: 9209: 9204: 9203: 9202: 9198: 9194: 9190: 9189: 9188: 9184: 9180: 9179:—— Shakescene 9176: 9172: 9168: 9167: 9166: 9162: 9158: 9151: 9150:edit conflict 9146: 9144: 9140: 9136: 9131: 9130: 9129: 9125: 9121: 9117: 9113: 9107: 9103: 9099: 9094: 9093: 9092: 9088: 9084: 9080: 9079: 9078: 9074: 9070: 9069:—— Shakescene 9066: 9061: 9057: 9049: 9045: 9041: 9036: 9035:the talk page 9032: 9031: 9030: 9026: 9022: 9018: 9017: 9016: 9012: 9008: 9003: 9002: 9001: 8997: 8993: 8989: 8984: 8980: 8976: 8975: 8974: 8973: 8969: 8965: 8961: 8957: 8953: 8952:featured list 8949: 8929: 8925: 8921: 8917: 8916: 8915: 8911: 8907: 8903: 8902: 8901: 8897: 8893: 8889: 8885: 8881: 8877: 8876: 8875: 8874: 8873: 8872: 8863: 8859: 8855: 8851: 8850: 8849: 8845: 8841: 8837: 8832: 8831: 8830: 8826: 8822: 8818: 8817: 8816: 8812: 8808: 8804: 8800: 8796: 8792: 8789: 8769: 8765: 8761: 8756: 8752:added content 8748: 8747: 8746: 8742: 8738: 8734: 8730: 8725: 8721: 8720: 8719: 8715: 8711: 8706: 8703: 8698: 8697: 8696: 8692: 8688: 8684: 8679: 8678: 8677: 8673: 8669: 8665: 8662: 8658: 8654: 8651: 8647: 8646: 8645: 8641: 8637: 8625: 8624: 8623: 8619: 8615: 8606: 8599: 8595: 8591: 8590: 8589: 8585: 8581: 8577: 8573: 8570: 8567: 8563: 8558: 8557: 8555: 8554: 8553: 8552: 8551: 8550: 8543: 8539: 8535: 8527: 8523: 8522: 8521: 8517: 8513: 8509: 8508: 8507: 8503: 8499: 8494: 8493: 8492: 8491: 8487: 8483: 8479: 8468: 8464: 8460: 8456: 8452: 8448: 8447: 8446: 8445: 8441: 8437: 8433: 8429: 8393: 8389: 8385: 8381: 8378: 8377: 8376: 8372: 8368: 8364: 8360: 8355: 8351: 8350: 8349: 8345: 8341: 8336: 8335: 8334: 8330: 8326: 8322: 8318: 8317: 8316: 8312: 8308: 8304: 8300: 8296: 8291: 8287: 8283: 8279: 8274: 8271: 8270: 8269: 8265: 8261: 8257: 8254: 8250: 8247: 8242: 8238: 8235: 8231: 8228: 8227: 8226: 8222: 8218: 8214: 8210: 8206: 8202: 8197: 8194: 8190: 8185: 8184: 8183: 8179: 8175: 8170: 8166: 8163: 8160: 8159: 8158: 8154: 8150: 8146: 8142: 8137: 8136: 8135: 8131: 8128: 8125: 8120: 8115: 8111: 8110: 8109: 8105: 8101: 8096: 8091: 8087: 8084: 8080: 8076: 8072: 8071: 8070: 8066: 8062: 8058: 8054: 8049: 8045: 8041: 8040: 8039: 8035: 8031: 8026: 8025: 8019: 8015: 8010: 8002: 7998: 7994: 7986: 7983:Foo criteria 7976: 7972: 7968: 7964: 7961: 7958: 7955: 7952: 7949: 7946: 7943: 7940: 7937: 7933: 7932: 7926: 7922: 7918: 7914: 7910: 7906: 7898: 7888: 7887: 7874: 7870: 7866: 7862: 7856:elements and 7850: 7834: 7831: 7830: 7829: 7828: 7827: 7826: 7825: 7824: 7823: 7822: 7821: 7820: 7815:36 criterias 7814: 7812:28 criterias 7811: 7809:72 criterias 7808: 7807: 7796: 7777: 7774: 7773: 7772: 7768: 7764: 7760: 7754: 7750: 7735: 7724: 7721:The table in 7720: 7701: 7700: 7698: 7694: 7693: 7692: 7691: 7690: 7689: 7688: 7687: 7686: 7685: 7676: 7672: 7668: 7663: 7662: 7661: 7660: 7659: 7658: 7657: 7656: 7649: 7645: 7641: 7637: 7632: 7629: 7625: 7624: 7623: 7622: 7621: 7620: 7615: 7611: 7607: 7603: 7599: 7598: 7597: 7596: 7593: 7589: 7585: 7584:—— Shakescene 7580: 7579: 7578: 7577: 7573: 7569: 7563: 7561: 7557: 7551: 7549: 7543: 7535: 7534: 7531: 7526: 7525: 7520: 7500: 7496: 7492: 7491:—— Shakescene 7488: 7484: 7480: 7476: 7475: 7474: 7470: 7466: 7461: 7458: 7454: 7451: 7450: 7449: 7445: 7441: 7437: 7433: 7429: 7425: 7424: 7423: 7422: 7421: 7420: 7415: 7411: 7407: 7402: 7396: 7389: 7388: 7387: 7386: 7383: 7379: 7375: 7370: 7369: 7368: 7367: 7363: 7359: 7354: 7344: 7343: 7339: 7335: 7332: 7317: 7313: 7309: 7305: 7297: 7290: 7289: 7288: 7284: 7280: 7270: 7269: 7268: 7264: 7260: 7256: 7248: 7240: 7236: 7228: 7225: 7211: 7207: 7203: 7199: 7197: 7193: 7189: 7185: 7181: 7180: 7179: 7175: 7171: 7167: 7166: 7165: 7161: 7157: 7153: 7152: 7151: 7147: 7143: 7139: 7138: 7137: 7134: 7129: 7128: 7123: 7122: 7121: 7117: 7113: 7109: 7102: 7092: 7082: 7076: 7075: 7074: 7071: 7066: 7065: 7060: 7059:Template:Card 7055: 7054: 7053: 7052: 7048: 7044: 7037: 7033: 7029: 7024: 7008: 7004: 7000: 6996: 6995: 6994: 6991: 6986: 6985: 6980: 6979: 6978: 6974: 6970: 6966: 6953: 6943: 6942: 6940: 6936: 6928: 6922: 6916: 6915: 6913: 6912: 6911: 6907: 6903: 6898: 6894: 6893: 6892: 6888: 6884: 6879: 6875: 6874: 6873: 6869: 6865: 6861: 6857: 6856: 6855: 6851: 6848: 6845: 6841: 6837: 6833: 6832: 6831: 6827: 6823: 6820: 6816: 6812: 6811: 6810: 6809: 6806: 6801: 6800: 6795: 6791: 6790:Template:Card 6762: 6758: 6754: 6750:</del: --> 6745: 6744: 6743: 6739: 6735: 6715: 6714: 6713: 6709: 6705: 6698: 6690: 6689:strike though 6683: 6682:edit conflict 6678: 6676: 6672: 6668: 6664: 6662: 6658: 6653: 6652: 6651: 6647: 6644: 6641: 6637: 6636: 6635: 6631: 6627: 6623: 6622: 6621: 6617: 6613: 6609: 6607:Organization" 6605: 6604: 6603: 6599: 6595: 6589: 6577: 6561: 6560: 6559: 6555: 6551: 6539: 6532: 6531: 6530: 6526: 6522: 6518: 6516: 6512: 6508: 6504: 6500: 6496: 6495: 6494: 6490: 6486: 6482: 6481: 6480: 6477: 6475: 6469: 6467: 6460:<abbr: --> 6457: 6453: 6452: 6451: 6450: 6447: 6443: 6439: 6435: 6434: 6431: 6428: 6423: 6422: 6417: 6416: 6413: 6409: 6405: 6401: 6397: 6396: 6395: 6394: 6390: 6386: 6382: 6363: 6359: 6355: 6351: 6347: 6344: 6342: 6339: 6337: 6334: 6333: 6331: 6328: 6324: 6320: 6316: 6309: 6305: 6304: 6302: 6301: 6300: 6299: 6296: 6295: 6287: 6285: 6284:Lil_℧niquℇ №1 6279: 6266: 6262: 6258: 6250: 6249: 6244: 6240: 6236: 6232: 6229: 6225: 6224: 6222: 6218: 6214: 6213: 6212: 6207: 6205: 6201: 6197: 6192: 6191: 6188: 6178: 6174: 6170: 6165: 6162: 6157: 6153: 6152: 6151: 6147: 6144: 6141: 6133: 6132: 6131: 6130: 6126: 6125: 6118: 6113: 6105: 6076: 6072: 6068: 6064: 6063:WP:CONLIMITED 6060: 6056: 6051: 6050: 6049: 6046: 6039: 6037: 6036:Lil_℧niquℇ №1 6031: 6029: 6026: 6019: 6017: 6016:Lil_℧niquℇ №1 6010: 6005: 6004: 6003: 5999: 5995: 5991: 5985: 5978: 5977: 5976: 5975: 5974: 5973: 5972: 5971: 5970: 5969: 5960: 5957: 5950: 5948: 5947:Lil_℧niquℇ №1 5941: 5937: 5933: 5929: 5928: 5927: 5926: 5925: 5924: 5923: 5922: 5915: 5911: 5907: 5903: 5902: 5901: 5897: 5893: 5889: 5884: 5883: 5882: 5881: 5878: 5874: 5870: 5865: 5861: 5860: 5859: 5858: 5854: 5850: 5846: 5824: 5820: 5816: 5809: 5805: 5801: 5796: 5795: 5792: 5791: 5790: 5786: 5782: 5781:—— Shakescene 5776: 5770: 5766: 5765: 5764: 5760: 5756: 5752: 5747: 5746: 5745: 5741: 5737: 5732: 5728: 5724: 5723: 5722: 5721: 5720: 5719: 5714: 5710: 5706: 5702: 5699: 5694: 5687: 5680: 5677: 5674: 5668: 5661: 5657: 5656: 5655: 5654: 5651: 5647: 5643: 5639: 5635: 5631: 5627: 5623: 5620: 5617: 5614: 5613: 5604: 5600: 5596: 5590: 5587: 5582: 5578: 5574: 5569:"scope="col"" 5566: 5562: 5559: 5555: 5551: 5547: 5544: 5541: 5537: 5534: 5533: 5532: 5529: 5528:Jack Merridew 5524: 5519: 5515: 5511: 5506: 5502: 5498: 5497: 5496: 5495: 5494: 5493: 5488: 5484: 5480: 5475: 5472: 5468: 5463: 5462: 5461: 5460: 5457: 5454: 5453:Jack Merridew 5450: 5446: 5442: 5438: 5434: 5433: 5432: 5431: 5427: 5423: 5419: 5415: 5403: 5400: 5395: 5394: 5387: 5381: 5380: 5371: 5367: 5363: 5358: 5357: 5356: 5352: 5349: 5346: 5342: 5341: 5340: 5336: 5333: 5330: 5326: 5321: 5313: 5305: 5304: 5303: 5299: 5295: 5281: 5280: 5279: 5278: 5274: 5271: 5268: 5264: 5257:⁄<sub: --> 5237: 5234: 5233: 5230: 5227: 5220: 5209: 5202: 5190: 5186: 5183: 5180: 5175: 5174: 5170: 5165: 5160: 5159: 5156: 5152: 5148: 5144: 5140: 5136: 5135: 5133: 5132: 5130: 5114: 5110: 5107: 5104: 5099: 5095: 5091: 5090: 5089: 5086: 5085:Jack Merridew 5081: 5077: 5076: 5075: 5074: 5073: 5072: 5065: 5061: 5057: 5053: 5052: 5051: 5050: 5049: 5048: 5043: 5039: 5036: 5033: 5028: 5027: 5026: 5025: 5022: 5019: 5018:Jack Merridew 5014: 5013: 5012: 5011: 5007: 5004: 5001: 4996: 4989: 4988: 4986: 4980: 4977: 4973: 4968: 4962: 4959: 4955: 4935: 4932: 4931:Jack Merridew 4929:occurs, too. 4927: 4926: 4925: 4921: 4917: 4912: 4908: 4907: 4906: 4902: 4899: 4896: 4891: 4887: 4883: 4878: 4874: 4873: 4872: 4868: 4864: 4859: 4856: 4851: 4847: 4843: 4842: 4841: 4837: 4833: 4829: 4825: 4821: 4820: 4819: 4815: 4812: 4809: 4804: 4803: 4802: 4798: 4794: 4789: 4788: 4787: 4784: 4783:Jack Merridew 4779: 4778: 4755: 4751: 4747: 4742: 4741:Jack Merridew 4738: 4734: 4733: 4732: 4728: 4724: 4720: 4719: 4718: 4715: 4710: 4709: 4704: 4699: 4698: 4697: 4696: 4695: 4694: 4693: 4692: 4691: 4690: 4689: 4688: 4687: 4686: 4685: 4684: 4683: 4682: 4663: 4659: 4655: 4651: 4647: 4642: 4638: 4637: 4636: 4632: 4628: 4624: 4620: 4616: 4613: 4609: 4604: 4603: 4602: 4598: 4595: 4592: 4588: 4587: 4586: 4582: 4578: 4574: 4569: 4568: 4567: 4564: 4559: 4558: 4553: 4552: 4551: 4547: 4543: 4539: 4535: 4531: 4528: 4525: 4522: 4521: 4520: 4516: 4513: 4510: 4505: 4504: 4503: 4499: 4495: 4491: 4487: 4483: 4482: 4481: 4477: 4473: 4468: 4465: 4461: 4458: 4454: 4453: 4452: 4451: 4447: 4444: 4441: 4418: 4414: 4410: 4406: 4402: 4401: 4400: 4396: 4392: 4388: 4384: 4383: 4382: 4381: 4380: 4379: 4378: 4377: 4376: 4375: 4367: 4364: 4361: 4358: 4355: 4352: 4349: 4346: 4343: 4340: 4335: 4332: 4329: 4328: 4325: 4324: 4319: 4313: 4310: 4307: 4304: 4301: 4298: 4295: 4292: 4289: 4286: 4281: 4279: 4275: 4271: 4268: 4267: 4264: 4263: 4258: 4252: 4249: 4246: 4243: 4240: 4237: 4234: 4231: 4228: 4225: 4221: 4217: 4215: 4211: 4208: 4207: 4204: 4203: 4198: 4195: 4190: 4185: 4180: 4175: 4170: 4165: 4160: 4155: 4150: 4146: 4141: 4135: 4122: 4111: 4107: 4103: 4099: 4095: 4092: 4088: 4087: 4086: 4082: 4078: 4074: 4070: 4069: 4068: 4064: 4060: 4056: 4055: 4054: 4050: 4046: 4042: 4041: 4020: 4009: 4006: 4005: 4001: 4000: 3994: 3989: 3985: 3981: 3977: 3973: 3969: 3965: 3961: 3957: 3953: 3949: 3945: 3941: 3937: 3933: 3929: 3925: 3921: 3917: 3910: 3907: 3906: 3905: 3904: 3900: 3896: 3892: 3872: 3868: 3865: 3862: 3858: 3857: 3856: 3852: 3848: 3844: 3843: 3842: 3838: 3834: 3831:for details. 3830: 3825: 3821: 3820: 3819: 3815: 3811: 3807: 3806: 3805: 3802: 3797: 3796: 3791: 3787: 3786: 3785: 3784: 3780: 3776: 3772: 3768: 3767:accessibility 3752: 3749: 3745: 3744:accessibility 3736: 3735: 3734: 3732: 3720: 3717: 3712: 3708: 3704: 3703: 3702: 3701: 3697: 3693: 3689: 3685: 3684:WP:CONLIMITED 3678: 3660: 3657: 3652: 3651: 3645: 3644: 3643: 3642: 3641: 3640: 3639: 3638: 3637: 3636: 3635: 3634: 3623: 3619: 3615: 3611: 3608: 3604: 3603: 3602: 3601: 3600: 3599: 3598: 3597: 3596: 3595: 3586: 3583: 3578: 3577: 3572: 3568: 3564: 3563:Robert Rossen 3560: 3559: 3558: 3557: 3556: 3555: 3554: 3553: 3546: 3542: 3538: 3534: 3533:Robert Rossen 3530: 3526: 3525: 3524: 3523: 3522: 3521: 3516: 3513: 3508: 3507: 3502: 3498: 3497: 3496: 3495: 3494: 3493: 3489: 3485: 3481: 3471: 3470: 3467: 3462: 3461: 3456: 3451: 3449: 3445: 3441: 3436: 3432: 3428: 3424: 3404: 3401: 3396: 3395: 3390: 3389: 3388: 3382: 3374: 3370: 3366: 3362: 3361: 3360: 3357: 3352: 3351: 3346: 3341: 3340: 3339: 3335: 3331: 3324: 3323: 3322: 3319: 3314: 3313: 3308: 3307: 3304: 3300: 3296: 3288: 3284: 3283: 3282: 3281: 3275: 3268: 3261: 3255:Where should 3244: 3241: 3236: 3235: 3230: 3224: 3221: 3220: 3219: 3218: 3217: 3212: 3209: 3204: 3203: 3198: 3194: 3190: 3187:cursor. With 3185: 3184: 3183: 3182: 3178: 3174: 3170: 3163: 3159: 3139: 3138: 3133: 3132: 3118: 3114: 3110: 3106: 3102: 3101: 3100: 3099: 3098: 3097: 3096: 3095: 3082: 3078: 3074: 3070: 3069: 3068: 3064: 3060: 3053: 3052: 3051: 3050: 3047: 3043: 3039: 3035: 3031: 3028: 3027: 3025: 3021: 3017: 3013: 3009: 3005: 3001: 3000: 2999: 2998: 2997: 2996: 2991: 2987: 2983: 2979: 2978: 2977: 2976: 2973: 2969: 2965: 2961: 2957: 2956: 2955: 2954: 2950: 2946: 2942: 2938: 2934: 2922: 2918: 2914: 2910: 2909:WP:User_pages 2905: 2904: 2901: 2898: 2893: 2892: 2886: 2885: 2884: 2883: 2879: 2875: 2871: 2860: 2859: 2854: 2852: 2847: 2845: 2837: 2833: 2815: 2812: 2807: 2800: 2793: 2792: 2791: 2790: 2789: 2788: 2787: 2786: 2785: 2770: 2767: 2762: 2761: 2756: 2752: 2751: 2750: 2747: 2742: 2735: 2725: 2718: 2714: 2713: 2712: 2709: 2704: 2703: 2698: 2695: 2694: 2693: 2692: 2689: 2684: 2669: 2668: 2665: 2661: 2657: 2652: 2642: 2641: 2637: 2633: 2629: 2621: 2616: 2613: 2612: 2611: 2609: 2597: 2593: 2589: 2585: 2576: 2575: 2574: 2573: 2569: 2565: 2560:Pigsonthewing 2556: 2550: 2540: 2539: 2535: 2531: 2527: 2523: 2513: 2512: 2508: 2504: 2499:Pigsonthewing 2495: 2489: 2479: 2478: 2474: 2470: 2456: 2452: 2448: 2443:Pigsonthewing 2439: 2432: 2431: 2430: 2426: 2422: 2418: 2414: 2410: 2406: 2402: 2401: 2400: 2399: 2395: 2391: 2386:Pigsonthewing 2382: 2376: 2366: 2365: 2361: 2357: 2352:Pigsonthewing 2348: 2342: 2330: 2327: 2324:has closed. ― 2323: 2319: 2318: 2317: 2316: 2313: 2309: 2305: 2301: 2297: 2285: 2281: 2277: 2273: 2269: 2265: 2261: 2259: 2255: 2251: 2247: 2246: 2245: 2244: 2241: 2238: 2235: 2232: 2228: 2213: 2210: 2205: 2204: 2199: 2198: 2197: 2193: 2189: 2184: 2183: 2182: 2181: 2180: 2179: 2178: 2177: 2170: 2167: 2162: 2161: 2156: 2152: 2151: 2150: 2149: 2148: 2147: 2142: 2137: 2132: 2127: 2126: 2125: 2124: 2121: 2117: 2113: 2109: 2105: 2104: 2103: 2102: 2098: 2094: 2081: 2077: 2073: 2069: 2065: 2061: 2055: 2051: 2047: 2039: 2035: 2034: 2033: 2029: 2025: 2020: 2019: 2018: 2017: 2014: 2011: 2006: 2005: 2000: 1999: 1998: 1997: 1993: 1989: 1979: 1975: 1974: 1973: 1967: 1964: 1963: 1962: 1959: 1957: 1952: 1942: 1941: 1937: 1933: 1918: 1917: 1913: 1909: 1905: 1889: 1885: 1884: 1879: 1875: 1872: 1868: 1867: 1866: 1863: 1858: 1857: 1852: 1851: 1850: 1849: 1846: 1842: 1838: 1833: 1832: 1831: 1830: 1826: 1825: 1820: 1816: 1811: 1807: 1803: 1799: 1795: 1782: 1778: 1777: 1772: 1768: 1765: 1762: 1758: 1757: 1756: 1755: 1751: 1747: 1742: 1725: 1722: 1717: 1716: 1711: 1707: 1702: 1701: 1700: 1696: 1692: 1687: 1668: 1664: 1660: 1659:—— Shakescene 1657: 1652: 1651: 1650: 1649: 1648: 1647: 1646: 1645: 1644: 1643: 1642: 1641: 1640: 1639: 1638: 1637: 1635: 1634: 1633: 1629: 1625: 1624:—— Shakescene 1621: 1616: 1615: 1614: 1610: 1606: 1602: 1598: 1597: 1596: 1592: 1588: 1587:—— Shakescene 1584: 1583: 1578: 1574: 1570: 1566: 1560: 1556: 1552: 1551:—— Shakescene 1549: 1545: 1541: 1537: 1533: 1529: 1528: 1527: 1523: 1519: 1515: 1514: 1513: 1509: 1505: 1504:—— Shakescene 1501: 1496: 1492: 1491:Windows Vista 1488: 1487: 1482: 1478: 1474: 1470: 1466: 1465: 1464: 1460: 1459: 1454: 1449: 1448: 1447: 1446: 1442: 1438: 1437:—— Shakescene 1434: 1430: 1426: 1422: 1421:Windows Vista 1418: 1414: 1410: 1408: 1402: 1389: 1386: 1381: 1380: 1374: 1373: 1372: 1368: 1364: 1360: 1359: 1358: 1354: 1353: 1347: 1342: 1341: 1340: 1336: 1332: 1325: 1324: 1315: 1311: 1310: 1304: 1299: 1298: 1297: 1294: 1289: 1288: 1283: 1279: 1278:screen reader 1275: 1274: 1273: 1269: 1268: 1262: 1258: 1253: 1252: 1251: 1248: 1243: 1242: 1236: 1232: 1228: 1224: 1220: 1219: 1218: 1215: 1211: 1207: 1206: 1205: 1204: 1200: 1199: 1193: 1188: 1183: 1180: 1175: 1173: 1170:I discovered 1169: 1161: 1160:Google Chrome 1157: 1154: 1150: 1147: 1143: 1142: 1141: 1139: 1134: 1132: 1128: 1121: 1110: 1103: 1099: 1095: 1091: 1090: 1085: 1084: 1083: 1082: 1076: 1070: 1066: 1064: 1057: 1053: 1041: 1035: 1029: 1025: 1023: 1016: 1015: 1014: 1012: 1007: 1002: 991: 961: 953: 952: 951: 943: 942: 941: 939: 923: 917: 911: 907: 905: 875: 868: 867: 866: 862: 858: 856: 852: 848: 839: 835: 833: 829: 825: 823: 819: 815: 807: 802: 801: 800: 799: 795: 794: 789: 788: 787: 786: 782: 778: 774: 773: 768: 767: 762: 758: 754: 753: 742: 737: 736: 735: 733: 729: 720: 719: 718: 715: 698: 695: 690: 689: 684: 683: 682: 678: 674: 672: 668: 664: 655: 654: 653: 650: 645: 644: 639: 638: 637: 634: 629: 628: 623: 619: 618: 617: 614: 609: 608: 603: 599: 598: 591: 587: 583: 581: 577: 573: 565: 561: 559: 555: 551: 549: 545: 541: 533: 529: 524: 520: 519: 518: 515: 513: 507: 505: 499: 495: 489: 483: 479: 477: 470: 469: 468: 467: 466: 463: 462: 461: 451: 450: 449: 448: 444: 440: 438: 434: 430: 422: 418: 408: 407: 403: 399: 395: 371: 368: 363: 362: 357: 356: 355: 351: 347: 342: 337: 336: 335: 331: 327: 322: 313: 312: 311: 308: 306: 305: 300: 299: 298: 294: 290: 286: 285: 284: 281: 276: 275: 270: 269: 268: 267: 264: 261: 259: 258: 253: 252: 251: 249: 245: 243: 240: 237: 233: 227: 225: 221: 216: 214: 210: 204: 202: 196: 194: 193: 180: 177: 172: 171: 165: 164:screen reader 161: 160: 159: 158: 154: 150: 146: 143: 140: 137: 134: 131: 128: 125: 122: 119: 116: 103: 100: 97: 95: 92: 90: 87: 84: 80: 78: 75: 73: 70: 67: 65: 62: 61: 53: 49: 45: 44: 39: 32: 31: 23: 22:Accessibility 19: 12583: 12574: 12539: 12524: 12500: 12427: 12383: 12354: 12349: 12348: 12344: 12331:@Lil-unique1 12330: 12329: 12322: 12302:@Lil-unique1 12301: 12300: 12274: 12257:WhatamIdoing 12199:for editors, 12186:WhatamIdoing 12153: 12138: 12104:Andy's edits 12091:Andy Mabbett 12053: 12044:Andy's edits 12031:Andy Mabbett 12014: 11999: 11983: 11951:WhatamIdoing 11944: 11932:Andy's edits 11919:Andy Mabbett 11910: 11888:Andy's edits 11875:Andy Mabbett 11848:Andy's edits 11835:Andy Mabbett 11741:Limitations 11682:Andy's edits 11669:Andy Mabbett 11641:Andy's edits 11628:Andy Mabbett 11614:Andy's edits 11601:Andy Mabbett 11552: 11536: 11517: 11492: 11462: 11459: 11441:Andy's edits 11428:Andy Mabbett 11420: 11393:Conclusion: 11386:Saskatchewan 11276: 11235: 11189: 11149: 11040:Plastikspork 10995:Plastikspork 10940:WhatamIdoing 10893: 10872: 10843: 10788: 10753: 10655: 10626: 10614: 10574: 10556: 10544: 10479: 10309:wicketkeeper 10209: 10184: 10143: 10127: 10070: 10049: 10045: 10041: 9997: 9980: 9947: 9944: 9920: 9904: 9843: 9830: 9818: 9795:Thanks. :-) 9765: 9739: 9734: 9731:colour-blind 9730: 9728: 9716: 9704: 9685: 9677: 9674: 9651: 9621: 9586: 9565: 9561: 9557: 9528: 9524: 9516: 9514: 9505: 9494: 9447: 9440: 9380: 9357: 9317: 9283: 9263: 9228: 8945: 8892:WhatamIdoing 8835: 8807:WhatamIdoing 8732: 8565: 8476: 8425: 8363:edit-warring 8353: 8320: 8294: 8200: 8143:needs to be 8094: 8082: 7970: 7966: 7848:36 criterias 7846:28 criterias 7844:72 criterias 7564: 7552: 7544: 7541: 7522: 7516: 7465:WhatamIdoing 7435: 7406:WhatamIdoing 7358:WhatamIdoing 7350: 7329: 7183: 7125: 7062: 7040: 6982: 6938: 6839: 6797: 6787: 6730:<del: --> 6726:<ins: --> 6722:<del: --> 6696: 6688: 6654: 6580: 6568: 6473: 6465: 6419: 6373: 6371: 6289: 6283: 6274: 6210: 6193: 6108: 6096: 6035: 6015: 5994:WhatamIdoing 5946: 5892:WhatamIdoing 5842: 5774: 5768: 5750: 5736:WhatamIdoing 5682: 5637: 5633: 5518:presentation 5517: 5513: 5512:text, which 5509: 5470: 5444: 5411: 5391: 5331: 5269: 5255:<sup: --> 5251: 5198: 5125: 5124: 4994: 4991: 4982: 4978: 4975: 4971: 4966: 4964: 4960: 4956: 4952: 4889: 4877:common sense 4855:recommending 4854: 4849: 4706: 4645: 4555: 4436: 4321: 4262:Space Oddity 4260: 4200: 3983: 3975: 3967: 3959: 3951: 3939: 3931: 3923: 3888: 3829:Help:Sorting 3823: 3793: 3771:Help:sorting 3766: 3760: 3731:Help:sorting 3728: 3711:Plastikspork 3688:WikiProjects 3681: 3648: 3574: 3504: 3484:Plastikspork 3477: 3458: 3452: 3430: 3420: 3392: 3372: 3348: 3310: 3287:navigational 3286: 3254: 3232: 3228: 3215: 3200: 3146:<del: --> 3142: 3134: 3109:WhatamIdoing 3034:WP:CONSENSUS 3008:WP:CONSENSUS 2964:WhatamIdoing 2959: 2940: 2936: 2930: 2889: 2869: 2866: 2850: 2843: 2829: 2806:Plastikspork 2799:timeline row 2777: 2758: 2741:Plastikspork 2700: 2683:Plastikspork 2675: 2648: 2625: 2605: 2583: 2568:Andy's edits 2555:Andy Mabbett 2546: 2528:if you wish 2519: 2507:Andy's edits 2494:Andy Mabbett 2485: 2473:push to talk 2466: 2451:Andy's edits 2438:Andy Mabbett 2394:Andy's edits 2381:Andy Mabbett 2372: 2360:Andy's edits 2347:Andy Mabbett 2338: 2303: 2299: 2293: 2290:on tool-tips 2250:WhatamIdoing 2231:overcoloured 2230: 2226: 2224: 2201: 2158: 2089: 2037: 2024:WhatamIdoing 2002: 1988:WhatamIdoing 1984: 1971: 1960: 1948: 1924: 1901: 1881: 1854: 1835:should do). 1822: 1806:MOS:COLLAPSE 1790: 1774: 1740: 1738: 1713: 1580: 1484: 1456: 1429:Apple Safari 1423:versions of 1404: 1398: 1377: 1350: 1307: 1285: 1265: 1257:test article 1239: 1196: 1187:MOS:COLLAPSE 1184: 1179:this comment 1176: 1172:this comment 1165: 1135: 1127:MOS:COLLAPSE 1114: 1109:MOS:COLLAPSE 1087: 1060: 1049: 1019: 1010: 1005: 1003: 989: 962: 959: 949: 935: 901: 854: 850: 846: 821: 817: 813: 793:WP:PIC#thumb 791: 770: 764: 760: 756: 752:WP:PIC#thumb 750: 748: 726: 716: 714: 686: 670: 666: 662: 641: 625: 605: 579: 575: 571: 547: 543: 539: 522: 511: 503: 473: 455: 454: 436: 432: 428: 414: 391: 359: 320: 303: 272: 256: 238: 230: 228: 224:WP:CONSENSUS 219: 217: 212: 206: 198: 190: 188: 168: 147: 144: 141: 138: 135: 132: 129: 126: 123: 120: 117: 113: 82: 47: 41: 12100:Andy's talk 12040:Andy's talk 11928:Andy's talk 11884:Andy's talk 11844:Andy's talk 11783:Side issue 11678:Andy's talk 11637:Andy's talk 11610:Andy's talk 11545:Aberystwyth 11437:Andy's talk 11372:Provinces: 11190:I see that 10804:removed. -- 9941:Small fonts 9554:Overlinking 9449:SMcCandlish 8656:point ;-)). 8321:Data tables 7863:Regards, -- 7761:Regards, -- 7733:attributes. 7702:The use of 7517:Please see 7483:ahnentafels 7440:Mike Serfas 7028:Vegaswikian 6751:. Cheers -- 6747:</s: --> 6329:by the W3C. 6136:scope="row" 6100:scope="col" 4641:good friend 4202:David Bowie 3984:scope="col" 3976:scope="col" 3968:scope="col" 3960:scope="col" 3952:scope="col" 3940:scope="col" 3932:scope="col" 3924:scope="col" 3833:Mike Serfas 3775:Mike Serfas 3773:? Thanks. 3260:Chinesetext 3229:italic text 3150:<em: --> 3105:color-blind 2681:? Thanks! 2564:Andy's talk 2522:|discussion 2503:Andy's talk 2447:Andy's talk 2390:Andy's talk 2356:Andy's talk 2339:Please see 2310:, thanks. ― 2227:overcolored 1798:Happy-melon 1582:ahnentafeln 1486:ahnentafeln 1407:ahnentafeln 1063:SMcCandlish 1022:SMcCandlish 983:<h#: --> 904:SMcCandlish 476:SMcCandlish 40:This is an 12066:User:RexxS 11553:N. Ireland 11504:Manchester 11501:Birmingham 11116:. Cheers, 10002:Farmbrough 9952:Farmbrough 8683:W3 Schools 8660:usability. 8612:about it. 8593:criterion. 7804:AAA level 7477:A look at 7457:Click here 7432:user style 7108:WP:MOSICON 6815:WP:MOSICON 6718:<s: --> 6538:Cards/core 6226:Provide a 6194:Provide a 6009:MOS:DISCOG 5954:(Talk 2Me) 5940:MOS:DISCOG 5667:XMLElement 5203:says that 5164:wikilawyer 4405:WT:DISCOGS 4387:WT:DISCOGS 4336:Format: LP 4282:Format: LP 3709:? Thanks! 3369:that forum 2982:Tom Danson 2960:everywhere 2941:everywhere 2649:A user of 2628:over there 2620:Larry Bird 2471:. - Dank ( 2300:discussion 2042:  1972:Coded as: 1956:WP:REFPUNC 1908:WFCforLife 1898:Resolution 1837:WFCforLife 1810:MOS:SCROLL 1746:WFCforLife 1739:I've been 1691:WFCforLife 1605:WFCforLife 1518:WFCforLife 1495:HP Deskjet 1417:George III 1413:Wilhelm II 1363:WFCforLife 1223:WFCforLife 622:my sandbox 398:Knepflerle 102:Archive 15 94:Archive 13 89:Archive 12 83:Archive 11 77:Archive 10 12339:WP:ACCESS 12062:WP:ACCESS 11529:Inverness 11523:Edinburgh 11510:Liverpool 11101:Bar graph 11081:Bar graph 11033:Bar graph 10770:WP:ACCESS 10756:WP:ACCESS 10397:WP:ACCESS 9568:WP:ACCESS 8979:WP:ACCESS 8960:WP:ACCESS 8956:WP:ACCESS 8628:image map 8282:WP:JARGON 8246:chocapics 8119:WP:ACCESS 8114:WP:ACCESS 8043:projects. 7842:AAA level 7801:AA level 7257:. Yours, 6292:(talk2me) 6043:(talk2me) 6023:(talk2me) 5693:TOC limit 5195:Fractions 4967:generally 4846:confirmed 3677:Consensus 3197:Emacspeak 3162:retconned 3129:On strike 3024:WP:ACCESS 3016:WP:ACCESS 3004:WP:ACCESS 2933:WP:ACCESS 2530:GnevinAWB 2038:Coded as: 1904:this list 1794:WP:ACCESS 1168:WT:ACCESS 1131:talk page 1094:Eubulides 938:MediaWiki 861:talk to Ω 828:talk to Ω 777:Eubulides 761:Thumbnail 757:Thumbnail 677:talk to Ω 586:talk to Ω 554:talk to Ω 528:WP:LAYOUT 443:talk to Ω 346:Eubulides 72:Archive 9 64:Archive 5 12550:Dodoïste 12486:Dodoïste 12365:Dodoïste 12306:Dodoïste 12275:increase 11727:England 11518:Scotland 11405:Dodoïste 11398:Flatlist 11356:Flatlist 11310:Dodoïste 11303:Flatlist 11263:Dodoïste 11255:Flatlist 11195:Flatlist 11172:Dodoïste 11118:Dodoïste 11064:Frietjes 11016:Dodoïste 10980:Frietjes 10918:Dodoïste 10879:Frietjes 10849:Dodoïste 10825:Dodoïste 10730:Dodoïste 10680:Dodoïste 10595:Dodoïste 10190:Dodoïste 10166:Dodoïste 10087:Dodoïste 10052:Dodoïste 10022:Dodoïste 9983:Dodoïste 9891:Dodoïste 9797:Dodoïste 9688:Dodoïste 9540:Dodoïste 9477:Dodoïste 9460:Contribs 9383:alt text 9375:this map 9340:Dodoïste 9325:Dodoïste 9305:Dodoïste 9290:Dodoïste 9235:WereWolf 9193:Dodoïste 9135:Dodoïste 9120:Quiddity 9083:Dodoïste 9021:WereWolf 9007:Dodoïste 8964:WereWolf 8906:Dodoïste 8854:Dodoïste 8821:Dodoïste 8760:Dodoïste 8710:Dodoïste 8668:Dodoïste 8614:Dodoïste 8534:Dodoïste 8498:Dodoïste 8459:Dodoïste 8384:Dodoïste 8340:Dodoïste 8260:Dodoïste 8209:WCAG 1.0 8205:SC 1.3.2 8174:Dodoïste 8061:Dodoïste 8055:made on 7840:AA level 7798:A level 7746:headings 7640:Dodoïste 7568:Dodoïste 7374:Dodoïste 7308:Dodoïste 7259:Dodoïste 7202:Dodoïste 7142:Dodoïste 6902:Dodoïste 6788:I think 6734:Dodoïste 6594:Dodoïste 6404:Dodoïste 6354:Dodoïste 6312:experts. 6257:Dodoïste 6169:Dodoïste 5906:Dodoïste 5849:Dodoïste 5705:Dodoïste 5595:Dodoïste 5467:MOS:LIST 5422:Dodoïste 5335:contribs 5273:contribs 5147:Dodoïste 5056:Dodoïste 4916:Dodoïste 4832:Dodoïste 4793:Dodoïste 4723:Dodoïste 4627:Dodoïste 4623:WCAG 2.0 4542:Dodoïste 4494:Dodoïste 4472:Dodoïste 4409:Dodoïste 4272:Labels: 4218:Format: 4102:Dodoïste 4059:Dodoïste 3895:Dodoïste 3847:Dodoïste 3810:Dodoïste 3020:WP:WIAFA 3014:dropped 2672:Timeline 2622:article. 2606:Over at 2588:Dodoïste 2413:WP:WIAFA 2072:Quiddity 2046:Quiddity 1787:Proposal 1493:(for an 1435:9.0.0.6 1282:ZoomText 1075:Contribs 1034:Contribs 916:Contribs 602:this one 523:internal 488:Contribs 242:contribs 20:‎ | 12472:anyway. 12408:always; 12173:status. 11995:!scope= 11755:Tables 11722:Reason 11585:Keith D 11558:Belfast 11542:Cardiff 11526:Glasgow 11493:England 11380:Alberta 11325:Keith D 11111:Bar box 11091:Bar box 11057:Bar box 10763:seealso 9860:further 9515:if you 9471:I just 8666:Yours, 8191:RNIB, ( 8079:WP:FACR 7838:A level 7727:caption 7708:rowspan 7704:colspan 7226:@RexxS: 6959:(i.e.) 6948:(i.e.) 6352:Yours, 6217:Latin-1 6200:Latin-1 5703:Yours, 5638:or more 5634:or more 5325:Andrwsc 5263:Andrwsc 4278:Mercury 4274:Philips 4212:Label: 3675:RfC on 3614:Philcha 3537:Philcha 3440:Braille 3435:grammar 3431:grammar 3329:Georgia 3294:Georgia 3073:Philcha 3058:Georgia 3038:Philcha 2945:Wikid77 2913:Wikid77 2874:Wikid77 2844:Chicken 2421:Philcha 2264:Florida 2188:Kudpung 2131:Jeepday 2112:Philcha 2093:Kudpung 1968:Spaced 1878:SkotyWA 1819:SkotyWA 1771:SkotyWA 1453:SkotyWA 1431:4, and 1427:3.5.7, 1346:SkotyWA 1330:Georgia 1303:SkotyWA 1261:SkotyWA 1192:SkotyWA 978:==Foo== 955:==Foo== 881:==Foo== 806:WP:RFPP 532:WP:HEAD 341:removed 189:In the 43:archive 12530:niquℇ 12350:@RexxS 12144:niquℇ 12094:(User: 12070:WP:FLC 12058:WP:MOS 12034:(User: 12025:WP:OWN 12005:niquℇ 11922:(User: 11878:(User: 11838:(User: 11769:Lists 11713:Topic 11672:(User: 11631:(User: 11604:(User: 11498:London 11431:(User: 11237:Graham 10895:Graham 10790:Graham 10657:Graham 10576:Graham 10423:; see 10261:under 10236:WP:FLC 10219:dagger 10101:WP:FLC 10072:Graham 9922:Graham 9919:Done. 9906:Graham 9767:Graham 9653:Graham 9623:Graham 9588:Graham 9267:Nathan 9251:Nathan 9208:Nathan 8920:Gnevin 8733:remove 8512:Gnevin 8482:Gnevin 8359:WP:BRD 8201:layout 8057:WP:ALT 7988:Level 7967:always 7900:Level 7695:Hello, 7524:Graham 7334:Gnevin 7170:Gnevin 7127:Graham 7112:Gnevin 7064:Graham 7043:Gnevin 6984:Graham 6864:Gnevin 6860:WP:IAR 6822:Gnevin 6799:Graham 6693:insert 6667:Gnevin 6657:Gnevin 6626:Gnevin 6521:Gnevin 6503:WP:ALT 6485:Gnevin 6462:tags? 6421:Graham 6385:Gnevin 6323:WebAIM 6235:Gnevin 6111:Imzadi 6059:WP:MOS 5558:WP:ALT 5550:WP:ALT 5471:misuse 5441:revert 5393:Graham 4995:having 4708:Graham 4557:Graham 4124:Album 3795:Graham 3682:Given 3650:Graham 3576:Graham 3529:Graham 3506:Graham 3474:Tables 3460:Graham 3394:Graham 3380:ɳorɑfʈ 3350:Graham 3312:Graham 3273:ɳorɑfʈ 3234:Graham 3202:Graham 3177:strike 3026:must: 3012:WP:FAC 2891:Graham 2851:monkey 2760:Graham 2702:Graham 2651:WP:AIR 2558:(User: 2497:(User: 2441:(User: 2417:WP:ALT 2409:WP:ALT 2405:WP:ALT 2384:(User: 2350:(User: 2203:Graham 2160:Graham 2108:WT:MOS 2004:Graham 1965:Common 1951:WT:MOS 1856:Graham 1802:ported 1715:Graham 1534:) but 1379:Graham 1287:Graham 1241:Graham 1136:Using 1056:WP:ALT 990:should 874:Anchor 732:WP:PIC 688:Graham 643:Graham 627:Graham 607:Graham 361:Graham 274:Graham 170:Graham 12505:RexxS 12456:RexxS 12280:RexxS 12220:RexxS 12052:That 11966:RexxS 11859:RexxS 11819:RexxS 11719:Rexx 11716:Andy 11652:RexxS 11570:RexxS 11561:Derry 11537:Wales 11507:Leeds 10806:RexxS 10517:poker 10503:RexxS 10437:RexxS 10335:RexxS 10279:RexxS 9876:RexxS 9783:RexxS 9750:RexxS 9735:blind 9650:Yes. 9517:don't 9456:ʕ(ل)ˀ 9454:Talk⇒ 9421:bamse 9407:RexxS 9388:bamse 9157:RexxS 9118:. -- 9098:RexxS 9040:RexxS 8992:RexxS 8840:RexxS 8737:RexxS 8687:RexxS 8636:RexxS 8580:RexxS 8436:RexxS 8367:RexxS 8325:RexxS 8307:RexxS 8248:! ;-) 8217:RexxS 8149:RexxS 8145:WP:6P 8141:WP:5P 8100:RexxS 8083:never 8047:time. 8030:RexxS 7941:Level 7858:scope 7738:scope 7731:scope 7667:RexxS 7606:RexxS 7436:spare 7279:RexxS 7238:used. 7188:RexxS 7156:RexxS 7081:Cards 6999:RexxS 6969:RexxS 6883:RexxS 6753:RexxS 6704:RexxS 6702:). -- 6612:RexxS 6550:RexxS 6507:JD554 6474:melon 6466:Happy 6438:RexxS 6067:RexxS 5869:RexxS 5815:RexxS 5755:RexxS 5642:RexxS 5626:plays 5576:here. 5479:RexxS 5437:added 5362:RexxS 5294:RexxS 4863:RexxS 4746:RexxS 4654:RexxS 4577:RexxS 4391:JD554 4214:Deram 4096:I've 4077:JD554 4045:JD554 4011:Year 3986:| SWE 3978:| FRA 3970:| CAN 3824:after 3696:there 3327:Sandy 3292:Sandy 3167:)? -- 3158:HTML5 3056:Sandy 3018:from 2632:Rsl12 2630:. -- 2280:stalk 2240:Adler 1500:JPEGs 1328:Sandy 1071:ʕ(ل)ˀ 1069:Talk⇒ 1030:ʕ(ل)ˀ 1028:Talk⇒ 945:==]== 912:ʕ(ل)ˀ 910:Talk⇒ 895:(and 512:melon 504:Happy 484:ʕ(ل)ˀ 482:Talk⇒ 192:Links 162:As a 121:e.g. 16:< 12554:talk 12526:Lil_ 12509:talk 12490:talk 12460:talk 12450:and 12428:both 12380:H.63 12369:talk 12310:talk 12284:talk 12261:talk 12224:talk 12190:talk 12140:Lil_ 12119:talk 12078:talk 12001:Lil_ 11970:talk 11955:talk 11863:talk 11823:talk 11656:talk 11589:talk 11574:talk 11471:talk 11409:talk 11343:talk 11329:talk 11314:talk 11289:talk 11267:talk 11221:talk 11176:talk 11157:talk 11122:talk 11068:talk 11020:talk 10984:talk 10959:talk 10944:talk 10922:talk 10883:talk 10853:talk 10844:Done 10829:talk 10810:talk 10778:talk 10734:talk 10707:talk 10684:talk 10636:talk 10620:lang 10599:talk 10564:talk 10529:talk 10507:talk 10486:talk 10455:talk 10441:talk 10405:talk 10370:talk 10339:talk 10329:and 10317:talk 10283:talk 10277:? -- 10259:WCAG 10244:talk 10224:and 10194:talk 10185:Done 10170:talk 10160:(a). 10150:talk 10110:talk 10091:talk 10056:talk 10026:talk 9999:Rich 9987:talk 9966:See 9949:Rich 9895:talk 9880:talk 9874:. -- 9855:and 9801:talk 9787:talk 9754:talk 9692:talk 9642:talk 9612:talk 9576:talk 9544:talk 9481:talk 9445:. — 9425:talk 9411:talk 9392:talk 9344:talk 9329:talk 9309:talk 9294:talk 9271:talk 9255:talk 9239:talk 9212:talk 9197:talk 9183:talk 9161:talk 9139:talk 9124:talk 9102:talk 9087:talk 9073:talk 9044:talk 9025:talk 9011:talk 8996:talk 8968:talk 8924:talk 8910:talk 8896:talk 8858:talk 8844:talk 8825:talk 8811:talk 8764:talk 8741:talk 8714:talk 8691:talk 8672:talk 8640:talk 8632:area 8618:talk 8609:area 8602:area 8596:The 8584:talk 8538:talk 8530:area 8526:Lynx 8516:talk 8502:talk 8486:talk 8463:talk 8440:talk 8428:edit 8426:The 8388:talk 8371:talk 8344:talk 8329:talk 8311:talk 8278:G3.1 8264:talk 8221:talk 8178:talk 8153:talk 8104:talk 8065:talk 8034:talk 7975:RNIB 7924:AAA 7869:talk 7767:talk 7740:(or 7706:and 7671:talk 7644:talk 7610:talk 7604:. -- 7588:talk 7572:talk 7560:UAAG 7556:WCAG 7495:talk 7469:talk 7444:talk 7410:talk 7395:hide 7378:talk 7362:talk 7338:talk 7312:talk 7300:abbr 7293:abbr 7283:talk 7275:abbr 7263:talk 7231:abbr 7229:The 7206:talk 7192:talk 7186:. -- 7174:talk 7160:talk 7146:talk 7116:talk 7101:Card 7091:Card 7086:and 7047:talk 7032:talk 7003:talk 6973:talk 6906:talk 6887:talk 6868:talk 6826:talk 6792:and 6757:talk 6738:talk 6708:talk 6671:talk 6661:talk 6630:talk 6616:talk 6598:talk 6564:abbr 6554:talk 6525:talk 6511:talk 6505:. -- 6501:and 6489:talk 6442:talk 6408:talk 6389:talk 6358:talk 6325:and 6276:See 6261:talk 6239:talk 6221:JAWS 6204:JAWS 6173:talk 6116:1979 6071:talk 6065:. -- 5998:talk 5910:talk 5896:talk 5873:talk 5853:talk 5819:talk 5806:(or 5785:talk 5775:skin 5759:talk 5751:skin 5740:talk 5709:talk 5646:talk 5628:and 5599:talk 5510:bold 5483:talk 5445:bold 5426:talk 5386:frac 5366:talk 5329:talk 5312:frac 5298:talk 5267:talk 5219:frac 5208:frac 5151:talk 5139:here 5129:here 5060:talk 4985:here 4920:talk 4890:that 4886:here 4882:here 4867:talk 4836:talk 4797:talk 4750:talk 4727:talk 4658:talk 4631:talk 4581:talk 4546:talk 4498:talk 4476:talk 4413:talk 4395:talk 4344:105 4106:talk 4091:JAWS 4081:talk 4075:. -- 4063:talk 4049:talk 4034:SWE 4031:FRA 4028:CAN 3962:| US 3954:| UK 3899:talk 3851:talk 3837:talk 3814:talk 3790:Lynx 3779:talk 3707:this 3698:. -- 3618:talk 3571:JAWS 3541:talk 3527:Hi, 3488:talk 3480:this 3334:Talk 3299:Talk 3227:and 3189:JAWS 3160:has 3152:and 3113:talk 3077:talk 3063:Talk 3042:talk 3032:get 2986:talk 2968:talk 2949:talk 2917:talk 2878:talk 2664:talk 2636:talk 2592:talk 2584:Done 2534:talk 2526:vote 2425:talk 2326:AoV² 2312:AoV² 2298:for 2276:talk 2268:ties 2254:talk 2237:Hans 2192:talk 2136:talk 2116:talk 2097:talk 2076:talk 2066:and 2050:talk 2028:talk 1992:talk 1936:talk 1932:Erik 1912:talk 1873:and 1841:talk 1808:and 1766:and 1761:bold 1750:talk 1741:bold 1706:Lynx 1695:talk 1663:talk 1628:talk 1609:talk 1591:talk 1555:talk 1522:talk 1508:talk 1441:talk 1367:talk 1335:Talk 1227:talk 1214:talk 1146:LYNX 1098:talk 1058:. — 781:talk 530:and 402:talk 350:talk 330:talk 321:Done 304:xeno 293:talk 257:xeno 236:talk 213:i.e. 201:JAWS 153:talk 12587:Two 12578:One 12098:); 12038:); 11926:); 11882:); 11842:); 11676:); 11635:); 11608:); 11435:); 11388:... 11277:big 11210:TfD 10938:? 10627:not 10519:or 10271:or 9850:see 9819:At 8295:bad 8132:-- 8020:10 8007:12 7999:14 7971:any 7959:AAA 7927:36 7919:28 7916:AA 7911:72 7865:Lgd 7763:Lgd 7562:). 7249:et 6954:or 6939:not 6852:-- 6749:--> 6648:-- 6321:by 6255:". 6148:-- 5811:--> 5802:in 5353:-- 5187:-- 5111:-- 5040:-- 5008:-- 4903:-- 4850:can 4816:-- 4599:-- 4517:-- 4448:-- 4347:44 4341:26 4293:21 4290:16 4287:17 4194:SWI 4189:SWE 4184:NOR 4169:GER 4164:AUT 4159:AUS 4025:US 4022:UK 3996:... 3869:-- 3373:why 2562:); 2501:); 2445:); 2388:); 2354:); 1571:in 1011:and 453:--- 220:not 12556:) 12511:) 12492:) 12462:) 12398:2. 12371:) 12312:) 12286:) 12263:) 12226:) 12192:) 12121:) 12102:; 12080:) 12054:is 12042:; 11972:) 11957:) 11930:; 11886:; 11865:) 11846:; 11825:) 11817:-- 11680:; 11658:) 11639:; 11612:; 11591:) 11576:) 11568:-- 11473:) 11463:is 11439:; 11411:) 11401:}} 11395:{{ 11384:• 11378:• 11359:}} 11353:{{ 11345:) 11331:) 11316:) 11306:}} 11300:{{ 11291:) 11269:) 11258:}} 11252:{{ 11242:87 11223:) 11213:}} 11207:{{ 11198:}} 11192:{{ 11178:) 11159:) 11124:) 11114:}} 11108:{{ 11104:}} 11098:{{ 11094:}} 11088:{{ 11084:}} 11078:{{ 11070:) 11062:. 11060:}} 11054:{{ 11044:―Œ 11036:}} 11030:{{ 11022:) 10999:―Œ 10986:) 10976:}} 10970:{{ 10961:) 10946:) 10924:) 10900:87 10885:) 10855:) 10831:) 10812:) 10795:87 10780:) 10766:}} 10760:{{ 10736:) 10709:) 10686:) 10674:I 10662:87 10654:. 10638:) 10623:}} 10617:{{ 10601:) 10581:87 10566:) 10531:) 10509:) 10488:) 10457:) 10443:) 10421:}} 10415:{{ 10407:) 10389:— 10372:) 10357:— 10341:) 10319:) 10301:— 10285:) 10246:) 10232:}} 10226:{{ 10222:}} 10216:{{ 10196:) 10172:) 10152:) 10112:) 10093:) 10077:87 10069:. 10058:) 10028:) 10005:, 9989:) 9955:, 9927:87 9911:87 9897:) 9882:) 9863:}} 9857:{{ 9853:}} 9847:{{ 9836:: 9803:) 9789:) 9781:-- 9772:87 9756:) 9694:) 9683:. 9658:87 9644:) 9628:87 9614:) 9593:87 9578:) 9570:? 9546:) 9483:) 9427:) 9413:) 9394:) 9366:: 9346:) 9331:) 9311:) 9296:) 9273:) 9257:) 9241:) 9214:) 9199:) 9185:) 9163:) 9141:) 9126:) 9104:) 9089:) 9075:) 9046:) 9027:) 9013:) 8998:) 8970:) 8926:) 8912:) 8898:) 8886:, 8860:) 8846:) 8827:) 8813:) 8801:, 8766:) 8743:) 8716:) 8693:) 8674:) 8642:) 8620:) 8586:) 8540:) 8518:) 8504:) 8488:) 8465:) 8442:) 8390:) 8373:) 8346:) 8331:) 8313:) 8266:) 8223:) 8180:) 8155:) 8122:-- 8106:) 8098:-- 8095:is 8067:) 8036:) 8028:-- 8017:D 8012:C 8004:B 7996:A 7962:36 7956:28 7953:AA 7950:72 7908:A 7871:) 7854:th 7769:) 7742:id 7673:) 7646:) 7612:) 7590:) 7574:) 7529:87 7521:. 7497:) 7471:) 7446:) 7412:) 7398:}} 7392:{{ 7380:) 7364:) 7340:) 7314:) 7285:) 7265:) 7208:) 7194:) 7176:) 7162:) 7148:) 7132:87 7118:) 7110:. 7104:}} 7098:{{ 7094:}} 7088:{{ 7084:}} 7078:{{ 7069:87 7061:. 7049:) 7034:) 7005:) 6989:87 6975:) 6908:) 6889:) 6870:) 6828:) 6804:87 6759:) 6740:) 6710:) 6673:) 6632:) 6618:) 6600:) 6556:) 6541:}} 6535:{{ 6527:) 6513:) 6491:) 6444:) 6426:87 6410:) 6391:) 6383:? 6360:) 6263:) 6241:) 6175:) 6073:) 6000:) 5987:}} 5981:{{ 5912:) 5898:) 5875:) 5867:-- 5855:) 5821:) 5787:) 5761:) 5742:) 5711:) 5696:}} 5690:{{ 5670:}} 5664:{{ 5648:) 5601:) 5514:is 5485:) 5477:-- 5428:) 5398:87 5388:}} 5384:{{ 5368:) 5360:-- 5337:) 5315:}} 5309:{{ 5300:) 5275:) 5222:}} 5216:{{ 5211:}} 5205:{{ 5153:) 5062:) 4998:-- 4922:) 4869:) 4838:) 4799:) 4752:) 4744:-- 4729:) 4713:87 4660:) 4646:do 4633:) 4583:) 4562:87 4548:) 4500:) 4478:) 4415:) 4397:) 4368:— 4365:— 4362:— 4359:— 4356:— 4353:— 4350:— 4314:— 4311:— 4308:— 4305:— 4302:— 4299:— 4296:— 4276:, 4253:— 4250:— 4247:— 4244:— 4241:— 4238:— 4235:— 4232:— 4229:— 4226:— 4220:LP 4179:NZ 4174:NL 4154:US 4149:UK 4142:) 4108:) 4083:) 4065:) 4051:) 4043:-- 3990:|- 3946:|- 3918:|- 3901:) 3853:) 3839:) 3816:) 3800:87 3781:) 3715:―Œ 3655:87 3620:) 3581:87 3543:) 3511:87 3503:. 3490:) 3465:87 3399:87 3355:87 3347:. 3336:) 3317:87 3301:) 3263:}} 3257:{{ 3239:87 3207:87 3195:. 3179:) 3175:| 3173:on 3115:) 3079:) 3065:) 3044:) 2988:) 2970:) 2951:) 2919:) 2896:87 2880:) 2810:―Œ 2802:}} 2796:{{ 2783:}} 2779:{{ 2765:87 2745:―Œ 2737:}} 2731:{{ 2727:}} 2721:{{ 2707:87 2687:―Œ 2662:- 2658:. 2638:) 2594:) 2566:; 2536:) 2505:; 2475:) 2449:; 2427:) 2392:; 2377:. 2358:; 2343:. 2282:) 2278:| 2256:) 2229:/ 2208:87 2194:) 2165:87 2157:. 2118:) 2099:) 2078:) 2052:) 2030:) 2009:87 1994:) 1938:) 1914:) 1861:87 1843:) 1752:) 1720:87 1697:) 1665:) 1630:) 1611:) 1593:) 1557:) 1524:) 1510:) 1443:) 1409:") 1405:(" 1384:87 1369:) 1337:) 1301:-- 1292:87 1284:. 1246:87 1229:) 1212:- 1123:}} 1117:{{ 1100:) 1092:. 1017:— 1006:is 877:}} 871:{{ 863:) 853:* 849:= 843:— 830:) 820:* 816:= 810:— 783:) 693:87 679:) 669:* 665:= 659:— 648:87 632:87 624:. 612:87 588:) 578:* 574:= 568:— 556:) 546:* 542:= 536:— 456:— 445:) 435:* 431:= 425:— 404:) 366:87 352:) 332:) 295:) 279:87 226:. 175:87 155:) 98:→ 68:← 12552:( 12534:1 12532:№ 12528:℧ 12507:( 12488:( 12458:( 12367:( 12308:( 12282:( 12259:( 12222:( 12188:( 12169:. 12148:1 12146:№ 12142:℧ 12117:( 12076:( 12009:1 12007:№ 12003:℧ 11968:( 11953:( 11861:( 11821:( 11654:( 11587:( 11572:( 11555:: 11539:: 11520:: 11495:: 11469:( 11407:( 11341:( 11327:( 11312:( 11287:( 11265:( 11219:( 11174:( 11155:( 11120:( 11066:( 11018:( 10982:( 10957:( 10942:( 10920:( 10881:( 10851:( 10827:( 10808:( 10776:( 10732:( 10705:( 10682:( 10634:( 10597:( 10562:( 10527:( 10505:( 10484:( 10453:( 10439:( 10418:† 10403:( 10387:C 10384:F 10381:W 10368:( 10355:C 10352:F 10349:W 10337:( 10315:( 10299:C 10296:F 10293:W 10281:( 10242:( 10192:( 10168:( 10148:( 10108:( 10089:( 10054:( 10024:( 9985:( 9974:: 9960:. 9893:( 9878:( 9799:( 9785:( 9752:( 9690:( 9640:( 9610:( 9574:( 9542:( 9479:( 9462:. 9423:( 9409:( 9390:( 9342:( 9327:( 9307:( 9292:( 9269:( 9253:( 9237:( 9210:( 9195:( 9181:( 9159:( 9152:) 9148:( 9137:( 9122:( 9100:( 9085:( 9071:( 9042:( 9023:( 9009:( 8994:( 8966:( 8922:( 8908:( 8894:( 8856:( 8842:( 8823:( 8809:( 8762:( 8739:( 8712:( 8689:( 8670:( 8638:( 8616:( 8582:( 8536:( 8514:( 8500:( 8484:( 8461:( 8438:( 8386:( 8369:( 8342:( 8327:( 8309:( 8262:( 8219:( 8176:( 8151:( 8130:C 8127:F 8124:W 8102:( 8063:( 8032:( 7947:A 7867:( 7765:( 7744:/ 7669:( 7642:( 7630:. 7608:( 7586:( 7570:( 7493:( 7467:( 7442:( 7408:( 7376:( 7360:( 7336:( 7310:( 7281:( 7261:( 7204:( 7190:( 7172:( 7158:( 7144:( 7114:( 7045:( 7030:( 7001:( 6971:( 6961:♥ 6950:♥ 6904:( 6885:( 6866:( 6850:C 6847:F 6844:W 6824:( 6755:( 6736:( 6706:( 6700:2 6697:A 6684:) 6680:( 6669:( 6659:( 6646:C 6643:F 6640:W 6628:( 6614:( 6596:( 6586:♥ 6583:2 6574:♥ 6571:A 6552:( 6523:( 6509:( 6487:( 6470:‑ 6440:( 6406:( 6387:( 6379:♥ 6376:A 6356:( 6259:( 6237:( 6171:( 6146:C 6143:F 6140:W 6122:→ 6069:( 5996:( 5908:( 5894:( 5871:( 5851:( 5817:( 5783:( 5757:( 5738:( 5707:( 5672:. 5644:( 5597:( 5542:. 5481:( 5424:( 5364:( 5351:C 5348:F 5345:W 5332:· 5327:( 5296:( 5289:2 5287:⁄ 5285:1 5270:· 5265:( 5244:2 5242:⁄ 5240:1 5235:½ 5185:C 5182:F 5179:W 5171:. 5149:( 5109:C 5106:F 5103:W 5058:( 5038:C 5035:F 5032:W 5006:C 5003:F 5000:W 4918:( 4901:C 4898:F 4895:W 4865:( 4834:( 4814:C 4811:F 4808:W 4795:( 4748:( 4725:( 4656:( 4629:( 4614:. 4597:C 4594:F 4591:W 4579:( 4544:( 4515:C 4512:F 4509:W 4496:( 4474:( 4459:. 4446:C 4443:F 4440:W 4411:( 4393:( 4138:( 4104:( 4079:( 4061:( 4047:( 3982:! 3974:! 3966:! 3958:! 3950:! 3938:! 3930:! 3922:! 3897:( 3867:C 3864:F 3861:W 3849:( 3835:( 3812:( 3777:( 3616:( 3539:( 3486:( 3332:( 3297:( 3171:( 3111:( 3075:( 3061:( 3040:( 2984:( 2966:( 2947:( 2915:( 2876:( 2634:( 2590:( 2532:( 2423:( 2274:( 2252:( 2190:( 2138:) 2134:( 2114:( 2095:( 2074:( 2048:( 2026:( 1990:( 1934:( 1910:( 1883:C 1839:( 1824:C 1776:C 1748:( 1693:( 1661:( 1626:( 1607:( 1589:( 1553:( 1520:( 1506:( 1458:C 1439:( 1365:( 1352:C 1348:| 1333:( 1309:C 1305:| 1267:C 1263:| 1225:( 1198:C 1194:| 1096:( 1077:. 1036:. 998:] 994:] 987:] 974:] 969:] 965:] 918:. 897:] 893:] 859:( 855:R 851:I 847:V 826:( 822:R 818:I 814:V 779:( 675:( 671:R 667:I 663:V 584:( 580:R 576:I 572:V 552:( 548:R 544:I 540:V 508:‑ 490:. 441:( 437:R 433:I 429:V 400:( 348:( 328:( 291:( 244:) 239:· 234:( 151:( 54:.

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

Knowledge

talk:Manual of Style/Accessibility/Archive 11 - Knowledge

Index