This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 9 | Archive 10 | Archive 11 | Archive 12 | Archive 13 | → | Archive 15 |
On many Wikipedia pages, temporal sequences are generated as HTML tables with "preceded by" and "succeeded by" cells in each row. For instance, [Jimmy Carter] is preceded by person x and followed by person y for several different public offices. These are stated in the following sequence:
1) Preceded by 2) Name of office 3) Followed by
e.g.
1) Preceded by Lester Maddox 2) Governor of Georgia 1971 – 1975 3) Succeeded by George Busbee
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
"Preceded by Lester Maddox Governor of Georgia 1971 – 1975 Succeeded by George Busbee"
might make more sense as
"Governor of Georgia 1971 – 1975 Preceded by Lester Maddox Succeeded by George Busbee"
which would be coded in the following sequence:
1) Governor of Georgia 1971 – 1975 2) Preceded by Lester Maddox 3) Succeeded by George Busbee
This would be a significant change involving thousands of pages so I'm putting it out for discussion.
Thisisnotatest ( talk) 06:43, 12 October 2009 (UTC)
In the Links section there is a caveat:
Some screen readers, such as earlier versions of JAWS, 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.
There is currently a discussion at Template talk:PRODWarning#Linked article name in section headings that raises the question of whether or not this is still an issue, i.e., is it unique to legacy versions? I would rather not download and install this program just to test it, and then uninstall it.
If someone can document that it is not 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 WP:CONSENSUS.
Happy Editing! — 141.156.161.245 ( talk · contribs) 15:36, 23 October 2009 (UTC)
A discussion about the use of icons without any supporting text is taking place at WT:FOOTY#National Team World Cup Tables - participants in this project may have useful input to give which would be very welcome there. Best, Knepflerle ( talk) 22:15, 27 October 2009 (UTC)
I've just readded the point about not placing links in heading titles. It was removed on
October 23, 2009, 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
Wikipedia:Accessibility#Links should probably be rewritten for clarity, though. The current content about screen readers isn't very relevant.
—
V = I * R (
talk to Ω)
14:44, 14 December 2009 (UTC)
While we're on the topic of funky section headers, is there any problem with this?
== Thumbnails {{Anchor|thumb}} ==
Template:Anchor says this won't work, but it was in WP:PIC for ages, and now that I've replaced it with:
== Thumbnails ==
{{Anchor|thumb}}
the result isn't as nice, as WP:PIC#thumb links to the first word in the Thumbnail section, whereas I want it to link to the word Thumbnail itself. For an example of anchors in section headers, and how it works for you, please click on #Anchor to this section header (the version I prefer) and on #Anchor to this section body (the version I don't like as much). Eubulides ( talk) 18:25, 15 December 2009 (UTC)
==Foo==
and want additional links to it, you can't just do this ==Foo{{Anchors|Bar|Baz}}==
, or yes, it will break. You have to do this: ==Foo{{Anchors|Foo|Bar|Baz}}==
. The heading will link perfectly fine as [[#Foo]]
(and [[#Bar]]
, 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. —
SMcCandlish
Talk⇒ ʕ(Õلō)ˀ
Contribs.
07:26, 18 January 2010 (UTC)What we really need is a new syntax of some kind in MediaWiki, something like:
==[[Head:Foo|Bar|Baz...]]==
such that any
==Foo==
can thereby by given additional anchor id's.
And since I think every [[Something:...]]
has a corresponding [[:Something:...]]
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 [[:Head:Foo]]
would create a heading that looked like the results of ==Foo==
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 <h#>
heading code in the HTML, but not ToC it. Under this scenario, I think that [[:Head:Foo|Bar|Baz]]
should produce the same results as [[:Head:Foo]]
(i.e., parameters after the first ignored) but [[:File:Filename|100px|right|thumb|Description.]]
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.
The rationale for doing any of this at all, of course, is that it is 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 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 and maintainability problem of rather high severity, and one that's been vexing me for over four years.
I was shocked by some of what I read in there, so I overhauled significant parts. 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 WP:ALT. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 06:57, 18 January 2010 (UTC)
Someone recently suggested they might try to have {{ footballbox collapsible}} deleted claiming that it's in violation of MOS:COLLAPSE. This has lead to some interesting discussion on the template talk page. 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...
Using 2009 Seattle Sounders FC season as my test case which makes extensive use of this template:
Also, in the archives of WT:ACCESS I discovered this comment which explains the behavior I observed above and seems to address most of the accessibility concerns related to collapsible content.
I've also discovered this comment 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 content is pertinant.
I would postulate that the verbage in MOS:COLLAPSE 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 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! -- SkotyWA T| C 07:27, 18 January 2010 (UTC)
I'm very interested in the answer to these questions, as another editor and I have just spent a month greatly expanding Grandchildren of Victoria and Albert, which uses collapsed genealogy boxes (" ahnentafeln") 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 Wilhelm II's direct descent from King George III) 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 Windows Vista versions of Mozilla Firefox 3.5.7, Apple Safari 4, and Netscape Navigator 9.0.0.6 —— Shakescene ( talk) 03:12, 29 January 2010 (UTC)
I've been bold 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. WFCforLife ( talk) 08:15, 30 January 2010 (UTC)
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 WP:ACCESS. The originial contributor of the section, Happy-melon, has already ported most of the pertinant information over to the main MOS article. I further propose that the MOS:COLLAPSE and MOS:SCROLL 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 indicated his approval of this as the outcome of this discussion (he pretty much suggested it). Does anyone have concerns with this plan of action? -- SkotyWA T C 17:50, 3 February 2010 (UTC)
I was wondering if someone can clarify the resolution guideline for me, in relation to this list? 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, WFCforLife ( talk) 22:16, 19 January 2010 (UTC)
Accolades in film articles and filmographies in actors' and filmmakers' articles are usually displayed in tables. In these tables, I often see the font-size: 90%
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 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?
Erik (
talk)
16:00, 26 January 2010 (UTC)
There's a dispute at WT:MOS this week that, in part, discusses whether we should require editors to place <ref> tags immediately adjacent to the associated text, without an intervening (non-breaking) space. WP:REFPUNC has taken a hands-off, no-edit-warring approach for years, although certainly a "most common" style exists, if you look through pages.
The systems under consideration look like this:
Coded as:
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. WhatamIdoing ( talk) 18:52, 13 February 2010 (UTC)
until I looked at the diff. Revert/fix at will :) --
Quiddity (
talk)
08:09, 14 February 2010 (UTC)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 politically correct, but edits to the page are only allowed on consensus.-- Kudpung ( talk) 08:53, 20 February 2010 (UTC)
I am guessing that this complaint was supposed to be about the guidance concerning the overcolored / overcoloured 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. [5] Hans Adler 11:33, 25 March 2010 (UTC)
I have listed Template:Tooltip for discussion. I figured I should mention it on this talk page because I based my rationale partly upon the accessibility guideline which says “Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text”. Please direct all responses to WP:TFD#Template:Tooltip, thanks. ― AoV² 06:46, 1 March 2010 (UTC)
Please see Wikipedia:Village pump (policy)#Policy of using Transparent image backgrounds. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:07, 24 March 2010 (UTC)
...despite my best efforts. Please see Proposal to remove alt text requirement. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:20, 24 March 2010 (UTC)
Feel free to revert the removal of the general style guidelines category if you like, but please see WT:MOS#General style guidelines. - Dank ( push to talk) 18:10, 7 April 2010 (UTC)
Discussion at MoS - Infobox headings has an accessibility component. Your views would be welcome. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:13, 8 April 2010 (UTC)
There is currently an ongoing |discussion about the future of this and others MoS naming style. Please consider the issues raise in the discussion and vote if you wish GnevinAWB ( talk) 20:48, 25 April 2010 (UTC)
Please note discussion of colours for species distribution maps, where input from people with accessibility expertise is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:45, 28 April 2010 (UTC)
Over at Manual of Style talk page for infoboxes, we're having a debate over titles for infoboxes, and we would like some input from the accessibility contingent. Here's what I know:
Which factor weighs more than the other? Are there other accessibility factors at play? Your input is welcomed over there. -- Rsl12 ( talk) 21:47, 7 May 2010 (UTC)
A user of WP:AIR 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 WT:AIR#Captions for line art. Chris Cunningham (not at work) - talk 08:52, 18 May 2010 (UTC)
Is it possible to specify alternative text for the images generated by <timeline>...</timeline>
? Thanks!
Plastikspork
―Œ(talk)
08:41, 5 June 2010 (UTC)
{{[[Template:timeline row |timeline row ]]}}
There is currently a discussion at WP:Village pump (policy)#The use of colors in filmographies which involves WP:ACCESS#Styles and markup options. Please join in that discussion if you so wish. Chicken monkey 23:42, 6 June 2010 (UTC)
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, talk-pages, or disambiguation pages (they're not considered articles, yet). Perhaps there was a compromise and someone concluded: "Resolution is fine if applied to articles, but don't make it affect the formatting of WP policy or guideline pages?" 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). - Wikid77 ( talk) 06:57, 7 June 2010 (UTC)
I have found widespread resistance, all across WP, to changing pages to conform with WP:ACCESS. The typical response is: "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". The resistance is not just in articles, or guideline formatting, but also in template formats, and everywhere, 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. - Wikid77 ( talk) 15:37, 7 June 2010 (UTC)
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, strikethrough in a discussion page most often denotes deleted text. This has a perfectly good semantic element (<del>
) that all visual user agents I've seen render with strikethrough style. Do screen readers also not indicate semantic text attributes, such as emphasis (<em>
and <strong>
) or side comments (as
HTML5 has
retconned <small>
)? --
Damian Yerrick (
on |
strike)
02:15, 15 June 2010 (UTC)
Where should {{ Chinesetext}} should go in an article? Before the infobox, or after? As an example, take St. Michael's Cathedral, Qingdao which sparked a bit of a debate, as it is up for FA. The infobox contains Chinese characters. ɳorɑfʈ Talk! 15:14, 20 June 2010 (UTC)
The item about spelling and grammar in the text section was directly lifted from a message I wrote about accessibility nearly four and a half years ago. I've taken the opportunity to clarify that it's only applicable to speech synthesizer users. I've also removed the mention of grammar from the item because grammar 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 Braille well, are poor spellers. See the New York Times article " With New Technologies, Do Blind People Lose More Than They Gain?" 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 one of my first major spelling mistakes inspired me to create a Wikipedia user page mentioning that I am blind.
I don't think for a moment that Wikipedia should abandon good spelling or grammar. I'm just not sure how important it is for the average speech synthesizer user who isn't a pedant like me. :-) Graham 87 14:38, 29 June 2010 (UTC)
Could someone tell me how this works with a screen reader? Plastikspork ( talk) 19:02, 29 June 2010 (UTC)
Given WP:CONLIMITED, to what extent and under what circumstances can individual WikiProjects and users customize article appearance with individual styles that deviate from site-wide style guidelines? Interested contributors are invited to participate there. -- Moonriddengirl (talk)
I recently added a method to Help:sorting, but I'm worried about something said there:
<span style="display:none">...</span>
, to ensure that each column has the desired sort mode. However, this technique creates tables that have
accessibility issues, as it causes problems with
screen readers and text browsers.|-style="display:none"
, which is probably better.I am not certain whether this caution applies only to rows made unsortable using class="sortbottom", or whether the text above means that the |-style="display:none"
is less troublesome in terms of accessibility. 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
Help:sorting? Thanks.
Mike Serfas (
talk)
18:17, 8 May 2010 (UTC)
A quick note on the recent update of our guidelines: this is the kind of tables an accessibility expert (also admin on the french Wikipedia) 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, Dodoïste ( talk) 16:53, 27 July 2010 (UTC)
{|class="wikitable"
- |-
- !scope="col" rowspan="2"| Year
- !scope="col" rowspan="2" width="300"| Album details
- !scope="col" colspan="5"| Peak chart positions
- |-
- !scope="col"| UK
- !scope="col"| US
- !scope="col"| CAN
- !scope="col"| FRA
- !scope="col"| SWE
- |-
...
Year | Album details | Peak chart positions | ||||
---|---|---|---|---|---|---|
UK | US | CAN | FRA | SWE |
Album | Album details | Peak chart positions |
Certifications ( sales thresholds) | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
UK | US | AUS | AUT | GER | NL | NZ | NOR | SWE | SWI | |||
David Bowie | — | — | — | — | — | — | — | — | — | — | ||
Space Oddity | 17 | 16 | 21 | — | — | — | — | — | — | — | ||
The Man Who Sold the World |
|
26 | 105 | 44 | — | — | — | — | — | — | — |
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 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, -- W F C-- 13:40, 3 August 2010 (UTC)
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 that took the initiative after discussion).
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 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.
That said, I do take RexxS' concern on board. Perhaps the following would be a good interim measure?
Images should
generallybe 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 under review.As a rule of thumb,Rowspans and colspansare best used in cases where they simplify the tableshould 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 here. Editors should take this into account when designing tables.
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 the other hand, asserting in the MoS that they are harmful without proof or having 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? -- W F C-- 16:07, 8 August 2010 (UTC)
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 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 here. Editors should take this into account when designing tables.
I've been looking around, but haven't been able to find an authoritive, definitive statement about how to deal with fractions. WP:Manual of Style (dates and numbers)#Fractions says that {{ frac}} 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 {{ frac}} poorly, especially within tables, and discussion on Template talk:Frac 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:
½ | 1⁄2 |
I have seen comments that screen readers will ignore the Unicode ½ but are those assertions true? How does the template output (which expands to <span class="frac"><sup>1</sup>⁄<sub>2</sub></span>
) sound in a screen reader or look in a text-based browser like Lynx? Some guidance from accessibility experts would be welcome, thanks! —
Andrwsc (
talk ·
contribs)
18:17, 5 August 2010 (UTC)
{{
frac}}
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.
Graham
87
03:41, 6 August 2010 (UTC)I recently added a paragraph about the issue with headings made out of bold text and ";", but I was reverted because there was no prior discussion. This paragraph is the translation of the first section of the French best practices for accessibility. Those best practices are written by an accessibility expert. I also saw this practice on the English Wikipedia here and there, so I assumed there wouldn't be any problem with it. Any thoughts? Dodoïste ( talk) 20:16, 8 August 2010 (UTC)
"scope="col""
in the guidelines about tables I told Danny B. (a fellow member of the
Accessibility initiative 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 here.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. For possible uses, see Wikipedia:Manual of Style (accessibility)/Definition list (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 {{ TOC limit}} to shorten it.
Like I said above, I still have tons of thing to add and improve here. Should I write them in a subpage of the Wikipedia:WikiProject Accessibility? So you could pick up any change you feel is ready to become part of the MOS, after you discussed it here? Dodoïste ( talk) 21:51, 9 August 2010 (UTC)
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 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 scope="col"
to the templates that create the table headers. We use rowspans a lot. Looking at
M-28 (Michigan highway), 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?
Imzadi
1979
→
03:21, 12 August 2010 (UTC)
scope="row"
have to be used in conjunction with a row header, or can it also be used on an ordinary first cell of a row? --
W
F
C--
03:41, 12 August 2010 (UTC)
To be changed to
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. See User:Lil-unique1/Accessibility and let me know what you think. Please do not edit the page but if there are errors do let me know. ... -- Lil_℧niquℇ №1 (talk2me) 23:23, 16 August 2010 (UTC)
Any guidance on non standard ASCII such as Gnevin ( talk) 09:31, 4 August 2010 (UTC)
?<abbr>
tags?
Happy‑
melon
16:05, 4 August 2010 (UTC)
<abbr title="spades">♠</abbr>
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. --
RexxS (
talk)
16:44, 4 August 2010 (UTC)
abbr
tag. Semantically speaking, <s>
is deprecated. <del>
is the tag that goes along with <ins>
. Now will you place the <del>
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!
Dodoïste (
talk)
11:05, 6 August 2010 (UTC)
I think Template:Card and Template:Cards 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. Graham 87 01:26, 5 August 2010 (UTC)
1) ♥ 2) ♥ or 3) ♥
1) ♥ 2) ♥ or 3) ♥
1) ♥ 2) ♥ or 3) ♥
<span title="hearts">♥</span>
(i.e.) ♥<abbr title="hearts">♥</abbr>
(i.e.)
♥Ok changes made. Can someone with a screen reader tell us how it reads Gnevin ( talk) 13:59, 16 August 2010 (UTC)
abbr
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 software to speak the abbreviation out loud. And the abbreviation will be useless.abbr
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. --
RexxS (
talk)
00:37, 17 August 2010 (UTC)
abbr
solution. Sorry about that. Nice to see you are able to use the WCAG 2.0.abbr
and contains an example of technique with an icon and alt text. A more accurate technique would be
F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information. 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".
Dodoïste (
talk)
12:47, 21 August 2010 (UTC)Wikipedia_talk:Username_policy#Are_symbols_as_usernames_allowable.3F Gnevin ( talk) 14:44, 19 August 2010 (UTC)
Scrolling lists and collapsible boxes cause problems for people with repetitive stress injuries 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 people with one of the most common physical disabilities? WhatamIdoing ( talk) 22:01, 3 May 2010 (UTC)
Please see Wikipedia talk:Missing Wikipedians#Accessibility problem with the use of the admin bullet. Graham 87 03:52, 27 August 2010 (UTC)
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:
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 Wikipedia:WikiProject Accessibility/Manual of style draft soon. And I will provide relevant techniques to produce accessible tables.
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) 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 ( WCAG). 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 ( UAAG).
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 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, Dodoïste ( talk) 22:48, 24 August 2010 (UTC)
colspan
and rowspan
attributes is definitely not an accessibility issue. If you want to improve Wikipedia'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
caption
element and the lack of scope
attributes.scope
(or id
/headings
) attributes in order to associate header cells and data.A level | AA level | AAA level |
---|---|---|
72 criterias | 28 criterias | 36 criterias |
th
elements and scope
attributes are enough to make it accessible.Level | Number of criteria |
---|---|
A | 72 |
AA | 28 |
AAA | 36 |
Level | Number of criteria |
---|---|
A | 14 |
B | 12 |
C | |
D | 10 |
The to "Images or colors inside a table" makes the guidance clearer and more useful. Can I just point out that WP:Manual of Style (accessibility)#Images 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. -- RexxS ( talk) 02:10, 29 August 2010 (UTC)
Template:Conservation status, 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 Gnevin ( talk) 15:23, 26 August 2010 (UTC)
area
tag is none of our concern. It's their job, we can't do a thing about it.
Dodoïste (
talk)
21:04, 27 August 2010 (UTC)area
tags. This is suboptimal. Software issues, software issues again... When will the Wikimedia Foundation employ an accessibility expert to fix their soup tag?area
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 about it.
Dodoïste (
talk)
23:35, 27 August 2010 (UTC)
image map
, 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 area
). 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 --
RexxS (
talk)
02:27, 28 August 2010 (UTC)
An editor created a timeline of the list of Red Hot Chili Peppers band members using a png file, and added it to the featured list. There was originally a timeline like this, but I had to remove it, since a featured list must meet all of the criteria, including WP:ACCESS. I'm not sure if this png file passes WP:ACCESS, and I'm not exactly sure how to check. Any information or confirmation is much appreciated. Thank you! WereWolf ( talk) 04:22, 5 September 2010 (UTC)
Just a question. Would we need to include the former touring musicians to the timeline, as well? WereWolf ( talk) 15:26, 6 September 2010 (UTC)
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. Nathan ( talk) 06:27, 14 September 2010 (UTC)
Hi. As promised most important parts of the table tutorial are now complete: Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Firsts comments and feedback are welcomed. As I am not a native speaker copyedit in sections marked as complete is welcomed too. ;-) Regards, Dodoïste ( talk) 01:55, 10 September 2010 (UTC)
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 tutorial talk page. Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Kind regards, Dodoïste ( talk) 20:31, 26 September 2010 (UTC)
Hi! I am new to WP:ACCESS and am trying to figure out how to make List_of_National_Treasures_of_Japan_(crafts:_swords) more accessible. Two issues have been raised in the (active) featured list candidacy:
As for "2.", I added alt text 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. bamse ( talk) 20:07, 17 September 2010 (UTC)
If anyone's an old hand at SVG maps and has some time to kill, please see Talk:Sexually transmitted disease#xs. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:01, 9 October 2010 (UTC)
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 image itself uses. Take for example the image File:World-Population-1800-2100.png, which is a graph that uses 5 colors, which means the image is not viewable if the webpage uses any of these colors.
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 and not assume the website is in control of the presentation.
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 on a transparent background are invisible. User:Blackbackground
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:
Do not overlink. Screen readers put each link on its own line.
Are sortable data tables exempt from this part of WP:ACCESS? The Rambling Man ( talk) 19:17, 2 January 2011 (UTC)
Thanks The Rambling Man for the cleanup you have done in this Manual of Style (accessibility), it is much appreciated. :-)
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 Wikipedia. But overlinking is not an accessibility 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 Wikipedia:WikiProject Usability/Readability guidelines.
In short, overlinking is evil. But it has nothing to do with accessibility specifically, so I removed it from this page. Yours, Dodoïste ( talk) 21:00, 15 January 2011 (UTC)
At present, we have the following guidance at the section WP:Manual of Style (accessibility)#Color on alternative methods of providing information conveyed by colour:
But in the section WP:Manual of Style (accessibility)#Text, we advise:
So, while I appreciate the fact that italic text may substitute for colour for colour-blind viewers, it seems to be unsuitable as a substitute for blind viewers (under default screen reader settings).
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. Philadelphia Phillies all-time roster (C)). At least one very experienced editor has found this apparent contradiction to be confusing and unhelpful (see User talk:The Rambling Man#MOS guidance), 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. -- RexxS ( talk) 17:47, 3 January 2011 (UTC)
At WP:Manual of Style (accessibility)#Links we currently have this guidance:
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 Help:Section#Section linking:
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 and neater organisation of sections within an article, avoiding multiple uses of {{ see}} and {{ further}} by replacing many of those with direct links within the section headers. See List of birds of Pennsylvania 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 his reply confirms my observations. -- RexxS ( talk) 22:39, 15 January 2011 (UTC)
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.
Rich
Farmbrough,
12:05, 23 December 2010 (UTC).
div.references { font-size: 100% !important; }
It should work, let me know if it doesn't. Yours, Dodoïste ( talk) 10:29, 16 January 2011 (UTC)
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.
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.
Any objections? Regards, Dodoïste ( talk) 11:46, 16 January 2011 (UTC)
In the tables section there's a link to Wikipedia:WikiProject Accessibility/Infobox accessibility. I checked the link out, but that very page says, as an intro:
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. The Rambling Man ( talk) 20:16, 16 January 2011 (UTC)
Following discussion at Wikipedia:FLC#Philadelphia Phillies_ all-time roster (C), which included the "invention" of templates such as {{ dagger}} and {{ double-dagger}} (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. WP:FLC. All the best, The Rambling Man ( talk) 20:38, 16 January 2011 (UTC)
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. The Rambling Man ( talk) 20:58, 17 January 2011 (UTC)
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:
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 just to be explicit that images should always be in the section to which they relate? The Rambling Man ( talk) 21:14, 16 January 2011 (UTC)
Could we expand on why we should use the {{ lang}} template? All I see here that it renders the same text as not 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. The Rambling Man ( talk) 21:30, 16 January 2011 (UTC)
I'm not sure what this section has to do with WP:ACCESS. 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 {{ seealso}} is informative, but leads to a page which is in no way related to the manual of style. Is this subsection of WP:ACCESS even relevant? The Rambling Man ( talk) 21:36, 16 January 2011 (UTC)
I would appreciate any comments concerning Template:Georgia, Largest cities, 2009 Census -- Bar Graph. 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. Frietjes ( talk) 01:25, 10 March 2011 (UTC)
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 Wikipedia (e.g. fair use) would need some local addition of 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? The Rambling Man ( talk) 18:51, 24 March 2011 (UTC)
I see that {{ Flatlist}} 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 this tool which counts transclusions of templates it's used 97 times across all of English Wikipedia. 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 advocating its use. To be fair, it's currently borderline {{ TfD}} material. It'd be nice to know...! The Rambling Man ( talk) 21:23, 16 January 2011 (UTC)
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, considering it's used 97 times across all of Wikipedia - 3.6 million articles) we should really work out if this is appropriate. If it is then we need to start telling people about it. Otherwise it's a dead end and the approach needs refining. The Rambling Man ( talk) 23:11, 18 January 2011 (UTC)
Topic | Andy | Rexx | Reason |
---|---|---|---|
England | "England" is not part of the list which includes London and Birmingham | "England" is part of the list which includes London and Birmingham | A header should be associated with the data in its scope |
Limitations | Claims to be familiar with the limitations of HTML lists in regard to headings | Doubts Andy's claim | Andy is unable to explain how "England" should be marked up |
Tables | Tables cannot be compared to lists | Tables and lists are intimately connected data structures | A table is a list of lists |
Lists | List data must be homogeneous | Homogeneity is a desirable, but unnecessary restriction, which does not account for the limitations of HTML markup | The list item acting as a header will be a label for the set of list data |
Side issue | This is a side issue | This is a side issue | This is a side issue |
Please note discussion below, at #Horizontal lists in navboxes, which I started earlier today, not knowing this topic was already in progress. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:39, 28 March 2011 (UTC)
I have asked a question about formatting a complex list at Wikipedia talk:Manual of Style (lists)#Complex_list_formatting. Since several people here know more than I about lists, and I'd be happy to have you look at it. Thanks, WhatamIdoing ( talk) 19:41, 28 March 2011 (UTC)
Is this part of the manual of style arbitary or not? I recently tried to make some access changes at
American Idol (season 10) 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 {| 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"
before they even begin to list content. Additionally there's very little use of !scope=
and an apparent disregard for color etc. —
Lil_℧niquℇ №1
[talk]
01:43, 1 April 2011 (UTC)
@Lil-unique1: 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, Dodoïste ( talk) 21:45, 1 April 2011 (UTC)
There was a significant controversy in Talk:American Idol (season 10)#Tables_and_accessibility about a guideline, among members of this accessibility project. We need to discuss this issue.
@Lil-unique1: To say it frankly, the case you are bringing up at American Idol (season 10) has little to do with WP:ACCESS 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, but somehow you stuck at your proposal.
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 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.
@RexxS: 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.
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 accessibility data tables tutorial does not mention this criteria. I moved it to the internal guidelines 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, Dodoïste ( talk) 21:45, 1 April 2011 (UTC)
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 9 | Archive 10 | Archive 11 | Archive 12 | Archive 13 | → | Archive 15 |
On many Wikipedia pages, temporal sequences are generated as HTML tables with "preceded by" and "succeeded by" cells in each row. For instance, [Jimmy Carter] is preceded by person x and followed by person y for several different public offices. These are stated in the following sequence:
1) Preceded by 2) Name of office 3) Followed by
e.g.
1) Preceded by Lester Maddox 2) Governor of Georgia 1971 – 1975 3) Succeeded by George Busbee
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
"Preceded by Lester Maddox Governor of Georgia 1971 – 1975 Succeeded by George Busbee"
might make more sense as
"Governor of Georgia 1971 – 1975 Preceded by Lester Maddox Succeeded by George Busbee"
which would be coded in the following sequence:
1) Governor of Georgia 1971 – 1975 2) Preceded by Lester Maddox 3) Succeeded by George Busbee
This would be a significant change involving thousands of pages so I'm putting it out for discussion.
Thisisnotatest ( talk) 06:43, 12 October 2009 (UTC)
In the Links section there is a caveat:
Some screen readers, such as earlier versions of JAWS, 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.
There is currently a discussion at Template talk:PRODWarning#Linked article name in section headings that raises the question of whether or not this is still an issue, i.e., is it unique to legacy versions? I would rather not download and install this program just to test it, and then uninstall it.
If someone can document that it is not 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 WP:CONSENSUS.
Happy Editing! — 141.156.161.245 ( talk · contribs) 15:36, 23 October 2009 (UTC)
A discussion about the use of icons without any supporting text is taking place at WT:FOOTY#National Team World Cup Tables - participants in this project may have useful input to give which would be very welcome there. Best, Knepflerle ( talk) 22:15, 27 October 2009 (UTC)
I've just readded the point about not placing links in heading titles. It was removed on
October 23, 2009, 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
Wikipedia:Accessibility#Links should probably be rewritten for clarity, though. The current content about screen readers isn't very relevant.
—
V = I * R (
talk to Ω)
14:44, 14 December 2009 (UTC)
While we're on the topic of funky section headers, is there any problem with this?
== Thumbnails {{Anchor|thumb}} ==
Template:Anchor says this won't work, but it was in WP:PIC for ages, and now that I've replaced it with:
== Thumbnails ==
{{Anchor|thumb}}
the result isn't as nice, as WP:PIC#thumb links to the first word in the Thumbnail section, whereas I want it to link to the word Thumbnail itself. For an example of anchors in section headers, and how it works for you, please click on #Anchor to this section header (the version I prefer) and on #Anchor to this section body (the version I don't like as much). Eubulides ( talk) 18:25, 15 December 2009 (UTC)
==Foo==
and want additional links to it, you can't just do this ==Foo{{Anchors|Bar|Baz}}==
, or yes, it will break. You have to do this: ==Foo{{Anchors|Foo|Bar|Baz}}==
. The heading will link perfectly fine as [[#Foo]]
(and [[#Bar]]
, 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. —
SMcCandlish
Talk⇒ ʕ(Õلō)ˀ
Contribs.
07:26, 18 January 2010 (UTC)What we really need is a new syntax of some kind in MediaWiki, something like:
==[[Head:Foo|Bar|Baz...]]==
such that any
==Foo==
can thereby by given additional anchor id's.
And since I think every [[Something:...]]
has a corresponding [[:Something:...]]
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 [[:Head:Foo]]
would create a heading that looked like the results of ==Foo==
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 <h#>
heading code in the HTML, but not ToC it. Under this scenario, I think that [[:Head:Foo|Bar|Baz]]
should produce the same results as [[:Head:Foo]]
(i.e., parameters after the first ignored) but [[:File:Filename|100px|right|thumb|Description.]]
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.
The rationale for doing any of this at all, of course, is that it is 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 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 and maintainability problem of rather high severity, and one that's been vexing me for over four years.
I was shocked by some of what I read in there, so I overhauled significant parts. 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 WP:ALT. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 06:57, 18 January 2010 (UTC)
Someone recently suggested they might try to have {{ footballbox collapsible}} deleted claiming that it's in violation of MOS:COLLAPSE. This has lead to some interesting discussion on the template talk page. 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...
Using 2009 Seattle Sounders FC season as my test case which makes extensive use of this template:
Also, in the archives of WT:ACCESS I discovered this comment which explains the behavior I observed above and seems to address most of the accessibility concerns related to collapsible content.
I've also discovered this comment 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 content is pertinant.
I would postulate that the verbage in MOS:COLLAPSE 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 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! -- SkotyWA T| C 07:27, 18 January 2010 (UTC)
I'm very interested in the answer to these questions, as another editor and I have just spent a month greatly expanding Grandchildren of Victoria and Albert, which uses collapsed genealogy boxes (" ahnentafeln") 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 Wilhelm II's direct descent from King George III) 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 Windows Vista versions of Mozilla Firefox 3.5.7, Apple Safari 4, and Netscape Navigator 9.0.0.6 —— Shakescene ( talk) 03:12, 29 January 2010 (UTC)
I've been bold 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. WFCforLife ( talk) 08:15, 30 January 2010 (UTC)
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 WP:ACCESS. The originial contributor of the section, Happy-melon, has already ported most of the pertinant information over to the main MOS article. I further propose that the MOS:COLLAPSE and MOS:SCROLL 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 indicated his approval of this as the outcome of this discussion (he pretty much suggested it). Does anyone have concerns with this plan of action? -- SkotyWA T C 17:50, 3 February 2010 (UTC)
I was wondering if someone can clarify the resolution guideline for me, in relation to this list? 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, WFCforLife ( talk) 22:16, 19 January 2010 (UTC)
Accolades in film articles and filmographies in actors' and filmmakers' articles are usually displayed in tables. In these tables, I often see the font-size: 90%
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 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?
Erik (
talk)
16:00, 26 January 2010 (UTC)
There's a dispute at WT:MOS this week that, in part, discusses whether we should require editors to place <ref> tags immediately adjacent to the associated text, without an intervening (non-breaking) space. WP:REFPUNC has taken a hands-off, no-edit-warring approach for years, although certainly a "most common" style exists, if you look through pages.
The systems under consideration look like this:
Coded as:
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. WhatamIdoing ( talk) 18:52, 13 February 2010 (UTC)
until I looked at the diff. Revert/fix at will :) --
Quiddity (
talk)
08:09, 14 February 2010 (UTC)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 politically correct, but edits to the page are only allowed on consensus.-- Kudpung ( talk) 08:53, 20 February 2010 (UTC)
I am guessing that this complaint was supposed to be about the guidance concerning the overcolored / overcoloured 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. [5] Hans Adler 11:33, 25 March 2010 (UTC)
I have listed Template:Tooltip for discussion. I figured I should mention it on this talk page because I based my rationale partly upon the accessibility guideline which says “Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text”. Please direct all responses to WP:TFD#Template:Tooltip, thanks. ― AoV² 06:46, 1 March 2010 (UTC)
Please see Wikipedia:Village pump (policy)#Policy of using Transparent image backgrounds. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:07, 24 March 2010 (UTC)
...despite my best efforts. Please see Proposal to remove alt text requirement. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:20, 24 March 2010 (UTC)
Feel free to revert the removal of the general style guidelines category if you like, but please see WT:MOS#General style guidelines. - Dank ( push to talk) 18:10, 7 April 2010 (UTC)
Discussion at MoS - Infobox headings has an accessibility component. Your views would be welcome. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:13, 8 April 2010 (UTC)
There is currently an ongoing |discussion about the future of this and others MoS naming style. Please consider the issues raise in the discussion and vote if you wish GnevinAWB ( talk) 20:48, 25 April 2010 (UTC)
Please note discussion of colours for species distribution maps, where input from people with accessibility expertise is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:45, 28 April 2010 (UTC)
Over at Manual of Style talk page for infoboxes, we're having a debate over titles for infoboxes, and we would like some input from the accessibility contingent. Here's what I know:
Which factor weighs more than the other? Are there other accessibility factors at play? Your input is welcomed over there. -- Rsl12 ( talk) 21:47, 7 May 2010 (UTC)
A user of WP:AIR 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 WT:AIR#Captions for line art. Chris Cunningham (not at work) - talk 08:52, 18 May 2010 (UTC)
Is it possible to specify alternative text for the images generated by <timeline>...</timeline>
? Thanks!
Plastikspork
―Œ(talk)
08:41, 5 June 2010 (UTC)
{{[[Template:timeline row |timeline row ]]}}
There is currently a discussion at WP:Village pump (policy)#The use of colors in filmographies which involves WP:ACCESS#Styles and markup options. Please join in that discussion if you so wish. Chicken monkey 23:42, 6 June 2010 (UTC)
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, talk-pages, or disambiguation pages (they're not considered articles, yet). Perhaps there was a compromise and someone concluded: "Resolution is fine if applied to articles, but don't make it affect the formatting of WP policy or guideline pages?" 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). - Wikid77 ( talk) 06:57, 7 June 2010 (UTC)
I have found widespread resistance, all across WP, to changing pages to conform with WP:ACCESS. The typical response is: "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". The resistance is not just in articles, or guideline formatting, but also in template formats, and everywhere, 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. - Wikid77 ( talk) 15:37, 7 June 2010 (UTC)
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, strikethrough in a discussion page most often denotes deleted text. This has a perfectly good semantic element (<del>
) that all visual user agents I've seen render with strikethrough style. Do screen readers also not indicate semantic text attributes, such as emphasis (<em>
and <strong>
) or side comments (as
HTML5 has
retconned <small>
)? --
Damian Yerrick (
on |
strike)
02:15, 15 June 2010 (UTC)
Where should {{ Chinesetext}} should go in an article? Before the infobox, or after? As an example, take St. Michael's Cathedral, Qingdao which sparked a bit of a debate, as it is up for FA. The infobox contains Chinese characters. ɳorɑfʈ Talk! 15:14, 20 June 2010 (UTC)
The item about spelling and grammar in the text section was directly lifted from a message I wrote about accessibility nearly four and a half years ago. I've taken the opportunity to clarify that it's only applicable to speech synthesizer users. I've also removed the mention of grammar from the item because grammar 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 Braille well, are poor spellers. See the New York Times article " With New Technologies, Do Blind People Lose More Than They Gain?" 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 one of my first major spelling mistakes inspired me to create a Wikipedia user page mentioning that I am blind.
I don't think for a moment that Wikipedia should abandon good spelling or grammar. I'm just not sure how important it is for the average speech synthesizer user who isn't a pedant like me. :-) Graham 87 14:38, 29 June 2010 (UTC)
Could someone tell me how this works with a screen reader? Plastikspork ( talk) 19:02, 29 June 2010 (UTC)
Given WP:CONLIMITED, to what extent and under what circumstances can individual WikiProjects and users customize article appearance with individual styles that deviate from site-wide style guidelines? Interested contributors are invited to participate there. -- Moonriddengirl (talk)
I recently added a method to Help:sorting, but I'm worried about something said there:
<span style="display:none">...</span>
, to ensure that each column has the desired sort mode. However, this technique creates tables that have
accessibility issues, as it causes problems with
screen readers and text browsers.|-style="display:none"
, which is probably better.I am not certain whether this caution applies only to rows made unsortable using class="sortbottom", or whether the text above means that the |-style="display:none"
is less troublesome in terms of accessibility. 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
Help:sorting? Thanks.
Mike Serfas (
talk)
18:17, 8 May 2010 (UTC)
A quick note on the recent update of our guidelines: this is the kind of tables an accessibility expert (also admin on the french Wikipedia) 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, Dodoïste ( talk) 16:53, 27 July 2010 (UTC)
{|class="wikitable"
- |-
- !scope="col" rowspan="2"| Year
- !scope="col" rowspan="2" width="300"| Album details
- !scope="col" colspan="5"| Peak chart positions
- |-
- !scope="col"| UK
- !scope="col"| US
- !scope="col"| CAN
- !scope="col"| FRA
- !scope="col"| SWE
- |-
...
Year | Album details | Peak chart positions | ||||
---|---|---|---|---|---|---|
UK | US | CAN | FRA | SWE |
Album | Album details | Peak chart positions |
Certifications ( sales thresholds) | |||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
UK | US | AUS | AUT | GER | NL | NZ | NOR | SWE | SWI | |||
David Bowie | — | — | — | — | — | — | — | — | — | — | ||
Space Oddity | 17 | 16 | 21 | — | — | — | — | — | — | — | ||
The Man Who Sold the World |
|
26 | 105 | 44 | — | — | — | — | — | — | — |
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 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, -- W F C-- 13:40, 3 August 2010 (UTC)
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 that took the initiative after discussion).
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 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.
That said, I do take RexxS' concern on board. Perhaps the following would be a good interim measure?
Images should
generallybe 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 under review.As a rule of thumb,Rowspans and colspansare best used in cases where they simplify the tableshould 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 here. Editors should take this into account when designing tables.
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 the other hand, asserting in the MoS that they are harmful without proof or having 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? -- W F C-- 16:07, 8 August 2010 (UTC)
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 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 here. Editors should take this into account when designing tables.
I've been looking around, but haven't been able to find an authoritive, definitive statement about how to deal with fractions. WP:Manual of Style (dates and numbers)#Fractions says that {{ frac}} 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 {{ frac}} poorly, especially within tables, and discussion on Template talk:Frac 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:
½ | 1⁄2 |
I have seen comments that screen readers will ignore the Unicode ½ but are those assertions true? How does the template output (which expands to <span class="frac"><sup>1</sup>⁄<sub>2</sub></span>
) sound in a screen reader or look in a text-based browser like Lynx? Some guidance from accessibility experts would be welcome, thanks! —
Andrwsc (
talk ·
contribs)
18:17, 5 August 2010 (UTC)
{{
frac}}
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.
Graham
87
03:41, 6 August 2010 (UTC)I recently added a paragraph about the issue with headings made out of bold text and ";", but I was reverted because there was no prior discussion. This paragraph is the translation of the first section of the French best practices for accessibility. Those best practices are written by an accessibility expert. I also saw this practice on the English Wikipedia here and there, so I assumed there wouldn't be any problem with it. Any thoughts? Dodoïste ( talk) 20:16, 8 August 2010 (UTC)
"scope="col""
in the guidelines about tables I told Danny B. (a fellow member of the
Accessibility initiative 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 here.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. For possible uses, see Wikipedia:Manual of Style (accessibility)/Definition list (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 {{ TOC limit}} to shorten it.
Like I said above, I still have tons of thing to add and improve here. Should I write them in a subpage of the Wikipedia:WikiProject Accessibility? So you could pick up any change you feel is ready to become part of the MOS, after you discussed it here? Dodoïste ( talk) 21:51, 9 August 2010 (UTC)
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 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 scope="col"
to the templates that create the table headers. We use rowspans a lot. Looking at
M-28 (Michigan highway), 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?
Imzadi
1979
→
03:21, 12 August 2010 (UTC)
scope="row"
have to be used in conjunction with a row header, or can it also be used on an ordinary first cell of a row? --
W
F
C--
03:41, 12 August 2010 (UTC)
To be changed to
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. See User:Lil-unique1/Accessibility and let me know what you think. Please do not edit the page but if there are errors do let me know. ... -- Lil_℧niquℇ №1 (talk2me) 23:23, 16 August 2010 (UTC)
Any guidance on non standard ASCII such as Gnevin ( talk) 09:31, 4 August 2010 (UTC)
?<abbr>
tags?
Happy‑
melon
16:05, 4 August 2010 (UTC)
<abbr title="spades">♠</abbr>
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. --
RexxS (
talk)
16:44, 4 August 2010 (UTC)
abbr
tag. Semantically speaking, <s>
is deprecated. <del>
is the tag that goes along with <ins>
. Now will you place the <del>
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!
Dodoïste (
talk)
11:05, 6 August 2010 (UTC)
I think Template:Card and Template:Cards 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. Graham 87 01:26, 5 August 2010 (UTC)
1) ♥ 2) ♥ or 3) ♥
1) ♥ 2) ♥ or 3) ♥
1) ♥ 2) ♥ or 3) ♥
<span title="hearts">♥</span>
(i.e.) ♥<abbr title="hearts">♥</abbr>
(i.e.)
♥Ok changes made. Can someone with a screen reader tell us how it reads Gnevin ( talk) 13:59, 16 August 2010 (UTC)
abbr
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 software to speak the abbreviation out loud. And the abbreviation will be useless.abbr
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. --
RexxS (
talk)
00:37, 17 August 2010 (UTC)
abbr
solution. Sorry about that. Nice to see you are able to use the WCAG 2.0.abbr
and contains an example of technique with an icon and alt text. A more accurate technique would be
F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information. 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".
Dodoïste (
talk)
12:47, 21 August 2010 (UTC)Wikipedia_talk:Username_policy#Are_symbols_as_usernames_allowable.3F Gnevin ( talk) 14:44, 19 August 2010 (UTC)
Scrolling lists and collapsible boxes cause problems for people with repetitive stress injuries 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 people with one of the most common physical disabilities? WhatamIdoing ( talk) 22:01, 3 May 2010 (UTC)
Please see Wikipedia talk:Missing Wikipedians#Accessibility problem with the use of the admin bullet. Graham 87 03:52, 27 August 2010 (UTC)
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:
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 Wikipedia:WikiProject Accessibility/Manual of style draft soon. And I will provide relevant techniques to produce accessible tables.
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) 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 ( WCAG). 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 ( UAAG).
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 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, Dodoïste ( talk) 22:48, 24 August 2010 (UTC)
colspan
and rowspan
attributes is definitely not an accessibility issue. If you want to improve Wikipedia'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
caption
element and the lack of scope
attributes.scope
(or id
/headings
) attributes in order to associate header cells and data.A level | AA level | AAA level |
---|---|---|
72 criterias | 28 criterias | 36 criterias |
th
elements and scope
attributes are enough to make it accessible.Level | Number of criteria |
---|---|
A | 72 |
AA | 28 |
AAA | 36 |
Level | Number of criteria |
---|---|
A | 14 |
B | 12 |
C | |
D | 10 |
The to "Images or colors inside a table" makes the guidance clearer and more useful. Can I just point out that WP:Manual of Style (accessibility)#Images 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. -- RexxS ( talk) 02:10, 29 August 2010 (UTC)
Template:Conservation status, 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 Gnevin ( talk) 15:23, 26 August 2010 (UTC)
area
tag is none of our concern. It's their job, we can't do a thing about it.
Dodoïste (
talk)
21:04, 27 August 2010 (UTC)area
tags. This is suboptimal. Software issues, software issues again... When will the Wikimedia Foundation employ an accessibility expert to fix their soup tag?area
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 about it.
Dodoïste (
talk)
23:35, 27 August 2010 (UTC)
image map
, 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 area
). 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 --
RexxS (
talk)
02:27, 28 August 2010 (UTC)
An editor created a timeline of the list of Red Hot Chili Peppers band members using a png file, and added it to the featured list. There was originally a timeline like this, but I had to remove it, since a featured list must meet all of the criteria, including WP:ACCESS. I'm not sure if this png file passes WP:ACCESS, and I'm not exactly sure how to check. Any information or confirmation is much appreciated. Thank you! WereWolf ( talk) 04:22, 5 September 2010 (UTC)
Just a question. Would we need to include the former touring musicians to the timeline, as well? WereWolf ( talk) 15:26, 6 September 2010 (UTC)
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. Nathan ( talk) 06:27, 14 September 2010 (UTC)
Hi. As promised most important parts of the table tutorial are now complete: Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Firsts comments and feedback are welcomed. As I am not a native speaker copyedit in sections marked as complete is welcomed too. ;-) Regards, Dodoïste ( talk) 01:55, 10 September 2010 (UTC)
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 tutorial talk page. Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Kind regards, Dodoïste ( talk) 20:31, 26 September 2010 (UTC)
Hi! I am new to WP:ACCESS and am trying to figure out how to make List_of_National_Treasures_of_Japan_(crafts:_swords) more accessible. Two issues have been raised in the (active) featured list candidacy:
As for "2.", I added alt text 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. bamse ( talk) 20:07, 17 September 2010 (UTC)
If anyone's an old hand at SVG maps and has some time to kill, please see Talk:Sexually transmitted disease#xs. — SMcCandlish Talk⇒ ʕ(Õلō)ˀ Contribs. 05:01, 9 October 2010 (UTC)
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 image itself uses. Take for example the image File:World-Population-1800-2100.png, which is a graph that uses 5 colors, which means the image is not viewable if the webpage uses any of these colors.
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 and not assume the website is in control of the presentation.
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 on a transparent background are invisible. User:Blackbackground
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:
Do not overlink. Screen readers put each link on its own line.
Are sortable data tables exempt from this part of WP:ACCESS? The Rambling Man ( talk) 19:17, 2 January 2011 (UTC)
Thanks The Rambling Man for the cleanup you have done in this Manual of Style (accessibility), it is much appreciated. :-)
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 Wikipedia. But overlinking is not an accessibility 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 Wikipedia:WikiProject Usability/Readability guidelines.
In short, overlinking is evil. But it has nothing to do with accessibility specifically, so I removed it from this page. Yours, Dodoïste ( talk) 21:00, 15 January 2011 (UTC)
At present, we have the following guidance at the section WP:Manual of Style (accessibility)#Color on alternative methods of providing information conveyed by colour:
But in the section WP:Manual of Style (accessibility)#Text, we advise:
So, while I appreciate the fact that italic text may substitute for colour for colour-blind viewers, it seems to be unsuitable as a substitute for blind viewers (under default screen reader settings).
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. Philadelphia Phillies all-time roster (C)). At least one very experienced editor has found this apparent contradiction to be confusing and unhelpful (see User talk:The Rambling Man#MOS guidance), 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. -- RexxS ( talk) 17:47, 3 January 2011 (UTC)
At WP:Manual of Style (accessibility)#Links we currently have this guidance:
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 Help:Section#Section linking:
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 and neater organisation of sections within an article, avoiding multiple uses of {{ see}} and {{ further}} by replacing many of those with direct links within the section headers. See List of birds of Pennsylvania 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 his reply confirms my observations. -- RexxS ( talk) 22:39, 15 January 2011 (UTC)
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.
Rich
Farmbrough,
12:05, 23 December 2010 (UTC).
div.references { font-size: 100% !important; }
It should work, let me know if it doesn't. Yours, Dodoïste ( talk) 10:29, 16 January 2011 (UTC)
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.
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.
Any objections? Regards, Dodoïste ( talk) 11:46, 16 January 2011 (UTC)
In the tables section there's a link to Wikipedia:WikiProject Accessibility/Infobox accessibility. I checked the link out, but that very page says, as an intro:
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. The Rambling Man ( talk) 20:16, 16 January 2011 (UTC)
Following discussion at Wikipedia:FLC#Philadelphia Phillies_ all-time roster (C), which included the "invention" of templates such as {{ dagger}} and {{ double-dagger}} (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. WP:FLC. All the best, The Rambling Man ( talk) 20:38, 16 January 2011 (UTC)
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. The Rambling Man ( talk) 20:58, 17 January 2011 (UTC)
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:
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 just to be explicit that images should always be in the section to which they relate? The Rambling Man ( talk) 21:14, 16 January 2011 (UTC)
Could we expand on why we should use the {{ lang}} template? All I see here that it renders the same text as not 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. The Rambling Man ( talk) 21:30, 16 January 2011 (UTC)
I'm not sure what this section has to do with WP:ACCESS. 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 {{ seealso}} is informative, but leads to a page which is in no way related to the manual of style. Is this subsection of WP:ACCESS even relevant? The Rambling Man ( talk) 21:36, 16 January 2011 (UTC)
I would appreciate any comments concerning Template:Georgia, Largest cities, 2009 Census -- Bar Graph. 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. Frietjes ( talk) 01:25, 10 March 2011 (UTC)
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 Wikipedia (e.g. fair use) would need some local addition of 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? The Rambling Man ( talk) 18:51, 24 March 2011 (UTC)
I see that {{ Flatlist}} 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 this tool which counts transclusions of templates it's used 97 times across all of English Wikipedia. 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 advocating its use. To be fair, it's currently borderline {{ TfD}} material. It'd be nice to know...! The Rambling Man ( talk) 21:23, 16 January 2011 (UTC)
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, considering it's used 97 times across all of Wikipedia - 3.6 million articles) we should really work out if this is appropriate. If it is then we need to start telling people about it. Otherwise it's a dead end and the approach needs refining. The Rambling Man ( talk) 23:11, 18 January 2011 (UTC)
Topic | Andy | Rexx | Reason |
---|---|---|---|
England | "England" is not part of the list which includes London and Birmingham | "England" is part of the list which includes London and Birmingham | A header should be associated with the data in its scope |
Limitations | Claims to be familiar with the limitations of HTML lists in regard to headings | Doubts Andy's claim | Andy is unable to explain how "England" should be marked up |
Tables | Tables cannot be compared to lists | Tables and lists are intimately connected data structures | A table is a list of lists |
Lists | List data must be homogeneous | Homogeneity is a desirable, but unnecessary restriction, which does not account for the limitations of HTML markup | The list item acting as a header will be a label for the set of list data |
Side issue | This is a side issue | This is a side issue | This is a side issue |
Please note discussion below, at #Horizontal lists in navboxes, which I started earlier today, not knowing this topic was already in progress. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:39, 28 March 2011 (UTC)
I have asked a question about formatting a complex list at Wikipedia talk:Manual of Style (lists)#Complex_list_formatting. Since several people here know more than I about lists, and I'd be happy to have you look at it. Thanks, WhatamIdoing ( talk) 19:41, 28 March 2011 (UTC)
Is this part of the manual of style arbitary or not? I recently tried to make some access changes at
American Idol (season 10) 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 {| 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"
before they even begin to list content. Additionally there's very little use of !scope=
and an apparent disregard for color etc. —
Lil_℧niquℇ №1
[talk]
01:43, 1 April 2011 (UTC)
@Lil-unique1: 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, Dodoïste ( talk) 21:45, 1 April 2011 (UTC)
There was a significant controversy in Talk:American Idol (season 10)#Tables_and_accessibility about a guideline, among members of this accessibility project. We need to discuss this issue.
@Lil-unique1: To say it frankly, the case you are bringing up at American Idol (season 10) has little to do with WP:ACCESS 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, but somehow you stuck at your proposal.
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 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.
@RexxS: 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.
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 accessibility data tables tutorial does not mention this criteria. I moved it to the internal guidelines 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, Dodoïste ( talk) 21:45, 1 April 2011 (UTC)