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 8 | Archive 9 | Archive 10 | Archive 11 | Archive 12 | → | Archive 15 |
What do people think of Family of Barack Obama ? Andy Mabbett | Talk to Andy Mabbett 22:43, 26 August 2008 (UTC)
[outdent] Accessibility isn't (at least not in this case) about complexity; this is the equivalent of drawing the family tree on paper, then placing it face-down and expecting someone to read it. If you can (and are sighted), view an instance of the template, in Firefox, using the "web Developer" toolbar with "miscellaneous - linerarize page" activated. Even after teh removal of huge anmuonts of white space, it looks like:
Elimelech Naomi Boaz Ruth Mahlon Orpah Chilion Obed Jesse David
See also Wikipedia:Accessibility#Layout tables
Folks,
I have had a go at an entirely different approach to drawing family trees.
If I could trouble you to have a look at User:Pee Tern/Sandbox/Template/Family tree chart/doc please ?
What do people think ?
Initial comments / suggestions / issues, here, please before I do much more work on it.
Also, for example, would "display:none;"s to give hidden column and row headings help ?
Please note that while definitely in the direction I think it should be going, it is still very much a work in progress !
Peet Ern ( talk) 12:45, 11 December 2008 (UTC)
← I think the semantically-correct and more accessible way to do this may be via nested lists, with suitable styling, of course. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:10, 13 December 2008 (UTC)
I made a version of a Barack Obama family tree here. Any thoughts? ~ Richmond96 t • c 03:22, 15 December 2008 (UTC)
the template {{
flatlist}} and its partner {{
endflatlist}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than characters which are read out ("one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. Example
Andy Mabbett |
Talk to Andy Mabbett 20:43, 28 August 2008 (UTC)
The use of a vertical bar character (or CSS equivalent) in place of the bullet character is not acceptable as the bar produced is not perfectly vertical and causes problems reading the lists as you go cross-eyed when there are short entries between the bars. The CSS mark-up needs to produce an unobtrusive character similar to the bullet when applied to lists. Keith D ( talk) 22:49, 5 September 2008 (UTC)
← "Long-standing consensus" can - and where it is harmful, should - be challenged. That said, I'm not insisting on the use of vertical-bar separators, and I don't know anyone else who is. I have already proposed two methods of using dot-shaped separators via CSS, and I've invited others to contribute alternatives. I am fully aware that accessibility is not just about blind users, or have I ever said or suggested such. Users using Braille display might not feel CSS separators; but who to they feel dot characters? How are lists rendered to them overall? Have you asked blind users whether they want to hear the word "dot" fifty or more tines as a separator? I have, and those users of audio browsers I have discussed the matter with most certainly do not. WCAG 1.0 tells us:
3.6 Mark up lists and list items properly. [Priority 2]
For example, in HTML, nest OL, UL, and DL lists properly. [1]
If you have evidence that WCAG is wrong, please cite it. The fact remains that - despite your unsupported assertion to the contrary - using in-line graphical characters as separators presents an accessibility barrier to some users and that marking up lists using in-line graphical characters, without using UL
or OL
and LI
elements, is semantic nonsense.
Andy Mabbett (User:Pigsonthewing);
Talk to Andy Mabbett;
Andy Mabbett's contributions 13:02, 6 September 2008 (UTC)
While I'm here...Pigonthewing's edits don't look right. "=" headings are not used, and WP:MOS already has guidance on how to nest subheadings; it's probably best not to do that in two places. Unless someone knows different, I'll revert. - Dan Dank55 ( send/receive) 20:53, 30 August 2008 (UTC)
A quick check shows the heading structure on every page to be broken, in the Wikipedia template (and thus outside the control of ordinary editors) - there is an H1 (the page title) immediately followed by an H3 ("From Wikipedia, the free encyclopedia"); and the page ends with a bunch of H5s ("Views", "Personal tools", "Navigation", "Search", "Interaction", "Toolbox") with no parent other than H1 (and the last headings in the article, which are not meant to apply to it). I raise this elsewhere, as soon as I have time. Andy Mabbett | Talk to Andy Mabbett 09:24, 31 August 2008 (UTC)
←How would you like to fix the heading structure on every page, and will the reader notice any difference? - Dan Dank55 ( send/receive) 16:18, 31 August 2008 (UTC)
Further info: WCAG says:
3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. ( [2])
and:
Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. ( [3])
On further reflection, "From Wikipedia, the free encyclopedia" isn't even a heading, and should probably be marked up as a paragraph. Andy Mabbett | Talk to Andy Mabbett 16:50, 31 August 2008 (UTC)
←
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 21:03, 31 August 2008 (UTC)
Pigs, I see that you've cited a non-Wikipedia source as your authority. The Wikimedia software apparently doesn't comply with this outside group's rules. What I want to know is what practical difference does it make for a disabled person? Imagine a page skips from Level 1 to Level 3 with no intervening Level 2 header. What problem does this create? Do the screen readers quit reading? WhatamIdoing ( talk) 21:23, 31 August 2008 (UTC)
Okay, so, aside from WhatamIdoing simply not believing what he's being told, that this addresses well-known and well-understood accessibility issues, the real question is where to put this? I'd be somewhat in favor of moving it to a more general guideline ( WP:LAYOUT seems like a likely target) and referencing that from here. By having it in the more general guideline, both the accessibility and semantic web issues can be mentioned without either sounding out-of-place — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)
Please see Template talk:Documentation#Heading fix. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:27, 8 September 2008 (UTC)
Simple succession boxes (like the second one here), seem OK, though they do lack headers, but complex cases, like this hypothetical example on the template documentation page, seem less so. Thoughts? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:54, 2 September 2008 (UTC)
←Thank you for a detailed response. Please bear in mind that the accessibility discussed here is specifically for people with a disability or other condition which can mean that their use of Wikipedia is not conducted in the same way, or using the same tools, as most of us use. That can include people who cannot see, and who have the pages read out loud to them by their computer. For such users, tables (which is how succession boxes are rendered), when used for layout rather than for tabular data, can be very problematic, because the software reads across rows; and because there is no header row or column to label the others. If you have Firefox, this effect can be simulated by using the "web Developer" extension, then selecting "Miscellaneous" then "Linearize Page". The table on Winston Churchill, while not perfect, and very long, is better than many, because it consists of simple rows. When, like in the hypothetical example discussed above, the first cell in a row covers multiple cells in the remaining columns, its accessibility is reduced. In that case, it can be read, in part, in the order:
and so on.
Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:18, 6 September 2008 (UTC)
I have just noticed this:
* Images now take their alt text from their alt= parameter, if one is present. ( r41837, bug 368)
in the Signpost archives. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:46, 23 November 2008 (UTC)
OK, it sounds as though we're getting a consensus, although we should probably wait a week or so to let others chime in. Maybe we should also post a public message about the need for alt text, and that we're considering an addition to the accessibility guidelines? Once everyone's on board, we should contact the FA authors, which we can maybe do by working our way down WP:WBFAN. As you say, L'Aquatique, there's no rush but it'd also be a nice gesture. When we start adding them ourselves, I'm probably best suited for math-y and science articles, but I'll volunteer for anything.
I just noticed something odd. I'm not sure how long it's been going on, but my screen readers no longer read the caption twice. I've been tinkering with settings, so that might've done the trick, or it might be part of the bugfix that Andy mentioned. Are others having the same experience? I'm inclined towards the latter explanation, because I seem to remember that the caption was repeated in the image alt text, if you looked at the HTML source. That's how I'd been explaining to myself why screen readers read the caption twice: once for the alt text and once for the caption itself. But now the alt text seems to be an empty string unless you specify one. Proteins ( talk) 14:37, 27 November 2008 (UTC)
Not having heard any opposition, I think we should be bold and add a requirement for alt text to the WP:ACCESS guidelines. To help people with that, perhaps we should update these instructions on writing good alt text for equations and images? Most editors will be unfamiliar with it, as I was, and we should make their learning curve as quick and easy as possible. I'll do my best with that, but most people here will know more than me — help would be appreciated! Proteins ( talk) 14:17, 5 December 2008 (UTC)
I updated WP:ACCESS and MOS:IMAGES as best I could, but please check them over. I also re-wrote the leads to WP:ALT and WP:CAP, but not yet their bodies. I wrote this script to check whether the images on a page have alt text. Longer-term, we should also think about updating pages such as
but perhaps it'd be wiser to see how this initial round of edits goes over. Once the idea of image alt text has had a chance to percolate through Wikipedia and once the guidelines are worked out, it should be safe to contact people at WT:FA, WP:WBFAN and WP:WPM to make their works more accessible. Proteins ( talk) 17:44, 5 December 2008 (UTC)
I have a query about the following guideline: "Images should be inside the section they belong to (after the header and after any links to other articles), and not just before the header." Is there any specific accessibility reason for this? Wikipedia:Manual of Style advises that editors should not "place left-aligned images directly below subsection-level (=== or greater) headings, as this can disconnect the heading from the text it precedes. This can often be avoided by shifting left-aligned images down a paragraph or two." However, sometimes for aesthetic reasons it seems better to place the image just before the subsection heading so that the heading and the text are in line. For example, if the subsection is short and has, say, only two or three paragraphs, placing the image lower down in the subsection can cause it to extend into the next section and create text alignment problems. — Cheers, JackLee – talk– 17:23, 27 November 2008 (UTC)
Wouldn't the caption or text tip be sufficient to provide the necessary context, though, since the very next bit of text would be the subsection heading anyway? I'm just wondering whether the guideline ought to be so rigid. It seems to me that there isn't much difference if the image caption is read just before the subheading, or the subheading is read just before the image caption by a screen reader. — Cheers, JackLee – talk– 07:01, 28 November 2008 (UTC)
Thanks for the clarification. I asked because another editor relocated an image in an article on the basis of compliance with this guideline. I didn't think that the change was really necessary, but didn't object to it. Nonetheless, I wanted to find out the rationale behind the guideline. Yes, other views on the matter are most welcome. — Cheers, JackLee – talk– 07:52, 28 November 2008 (UTC)
Perhaps, then, we should do away with the guideline stating that images should not be placed immediately after subsection-level headings. That rule and the rule regarding keeping images within sections place editors between a rock and a hard place when the subsection in question is short. — Cheers, JackLee – talk– 10:22, 28 November 2008 (UTC)
Seeing how this was in response to an edit I made, I would have appreciated a note informing me of this discussion, but that's okay. I don't know enough about screen readers to make a comment about it, so I'll trust whatever Graham87 says. I made the edits in question for two simple reasons: Images should go in the most relevant section. Suppose there was the section "Style B" and an image of this style. The image should be within this section and not right above it in section "Style A". It's really simple: images should go in the section they are relevant to, not right above the section in a different, irrelevant section. If you want to edit the image and text of the same topic, they shouldn't be in different edit sections.
Second, it looks better. Images shouldn't be to the side of a header yet both above and below it; it just looks really bad, especially when there's extra white space below it.
I see the problem of having a left-aligned image right under a 3rd level heading, but I don't personally care. The image is still in the correct relevant section, and the header, although separate from the text, is on top of the image. That isn't a big deal for me, but images really need to be in their relevant section, not right above. Reywas92 Talk 17:37, 28 November 2008 (UTC)
Phil, on my fairly standard screen using Firefox, this image obscures the edit button, so that's no good. I've played around with the CSS before, and it's frustrating; there are various codes that give me exactly what I want in the preview, but then obscure the edit button on the saved page.
Here's what we get when the image wikilink comes just before the subsection heading. Note the edit button is pushed just to the left of the image. - Dan Dank55 ( send/receive) 22:01, 28 November 2008 (UTC)
Someone recently edited a dab page to remove {{ TOCright}}, with an edit summary consisting of just " WP:ACCESS".
In reading this page, it says "Avoid floating the table of contents if possible," which seems like less of a prohibition than just a quick and maybemisleading summary of the linked-to section on Floating the TOC, which includes the line:
- A left-floated TOC may affect bulleted or numbered lists. Where it does, float the TOC to the right, or do not float it.
Dab pages follow different formatting rules than articles in any event; floating or suppressing the TOC is common practice, as the TOC doesn't really do a whole lot of good, and does disrupt the list flow.
Is there existing consensus on how TOCs should be handled on a dab page to accommodate both accessibility and general usability? Thanks, NapoliRoma ( talk) 17:21, 3 December 2008 (UTC)
Version 2.0 of the W3C's Web Content Accessibility Guidelines is now finished (see W3C Recommendation 11 December 2008; press release). It's very different to v1.0.
There is still no clear written policy (leastwise, none that I can find) mandating or recommending that those industry-standard guidelines should be followed, let alone to which level, on Wikipedia. I believe that there should be a clear policy that WCAG guidelines should be followed to a stated level; or at least that we should, as a body, strive towards doing so.
Does anyone have comments, and would people support such a move, and be willing to assist me in taking it forward? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:35, 13 December 2008 (UTC)
I'm not highly active here and I'm not presuming to give anyone advice. I have put off familiarizing myself with WCAG 2 until it was finalized, and I have just started to read about it. It is very large, and will take some time to understand. So personally, I won't commit to supporting it yet.
I have a reasonable understanding of WCAG 1 and the Samurai Errata, and I am comfortable working with them now. It is still possible to conform to 1.0, or both 1 and 2:
WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.
To this point we (en.Wikipedia) haven't officially committed to meeting any particular level of accessibility conformance (right?). I'd feel more comfortable launching an effort to evaluate articles' conformance levels—following any or all of these guidelines—as a way to gauge and improve accessibility. — Michael Z. 2009-01-06 06:20 z
So let me begin with these two questions (or set of questions in the latter case):
Having waded through part of WCAG 2, my recommendation is that we pretend it doesn't exist. The guidelines suffer from a bad case of second-system syndrome, and the authors don't seem to understand the boundaries between a webpage and the user-agent rendering the webpage: there are a number of guidelines where you can't say a webpage meets the guideline, you can only say that it doesn't actively interfere with meeting the guideline. -- Carnildo ( talk) 04:55, 9 January 2009 (UTC)
How does the main table in ISO 3166-2:GB render, in a screen-reader? Badly, I suspect, If so, we will need to find a better method for laying out the table (which currently has two lots of the same information, sorted differently), then ask for a bot to apply it to the many similar articles (see navbox at the foot of that page), one for each country. Would a simple, sortable table suffice? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:12, 14 December 2008 (UTC)
Template talk:Xt#Accessibility could use a third opinion about accessibility for this template. Thanks. — Michael Z. 2008-12-31 22:48 z
The "Images" section of this page states that images should have alt text (1) and that images should have captions (2). This gives me the impression that every image should have both alt text and a caption. At
Wikipedia:Alternative text for images, it is stated, "Every image, including math-mode equations, should specify alternative text (alt text)", but then there is an entire section called "When alternative text is unnecessary", which says "Alternative text may not be necessary if the caption itself suffices to describe the image". So now it appears a caption may warrant removal of alt text. Then at
Wikipedia:Captions, we have, "Not every Wikipedia image needs a caption" and "Regardless of whether you include a caption, all images should have alt text", so now maybe we can have alt text but no caption. Furthermore, many infoboxes such as {{
Infobox VG}} have a "caption" parameter that displays text under the image (specified with the "image" parameter)—is this a separate case from a caption given in the [[Image:...|caption]]
format, or is a caption a caption? I try to follow accessibility rules when I can, but this is extremely confusing and I would appreciate it if someone who is knowledgeable in this area can get these pages in sync so editors like me can tell what we're supposed to do.
Pagra
shtak 21:17, 2 January 2009 (UTC)
Wikipedia has a checklist called " The perfect article".
Here is a discussion on whether or not an inaccessible article can be called "perfect", where it has been suggested that WCAG guidelines "aren't appropriate for Wikipedia". Please feel free to contribute. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:37, 3 January 2009 (UTC)
Talk:Alexander Alekhine#Hidden solutions in diagrams: a number of articles on chess players and chess tactics include 'problems', where a chessboard is shown midway through a game, there being an optimal set of moves for one or other side thereafter. The captions on these pseudo-images include the sequence of moves, but hidden inside collapsible sections ( eg). I removed the hidden styling citing both accessibility and 'not censored' concerns, but was reverted. Comments are appreciated. Happy‑ melon 21:35, 6 January 2009 (UTC)
There's a discussion at Template talk:Infobox Weather#This template or template:Climate_chart about the use of {{ Infobox Weather}} vs. {{ Climate chart}} which both present the same kind of data but in completely different formats (one is a table of numbers with different color backgrounds to indicate coldness to hotness where the other is a bar chart). If there are accessibility reasons one of these should be preferred over the other please comment (there, not here). Thanks. -- Rick Block ( talk) 03:35, 9 January 2009 (UTC)
Hi, do the scrolling box things (see here) cause accessibility problems? Thanks Ling.Nut ( talk— WP:3IAR) 05:22, 14 January 2009 (UTC)
One thing I do like about WCAG 2 is that its Conformance section is very specific (although a bit complex). Before we can evaluate specific articles, we need to determine the baseline provided by the WikiMedia software, and its implementation in Wikipedia, and set some goals.
Checklists are available for WCAG 1 (sorted by priority), [6] and WCAG 2. [7]. — Michael Z. 2009-01-18 07:36 z
Are screen resolution and browsers without JavaScript. As far as I'm aware, the current consensus is that our pages should look acceptable on 800x600 (but no lower) and that all content should be accessible to users without JavaScript and CSS, although it is accepted that it may look inferior. However, these guidelines are not really laid out anywhere properly, this page seems the natural place to do so. This ties in well with MOS:SCROLL, which has always seemed rather out-of-place to me on the main MoS page when it's largely an accessibility issue. If that section were moved here (and the shortcut updated) it could be made clearer and more extensive without bulking up the main MoS page.
Largely to kickstart some discussion, I'll throw out some proposed wording. How about replacing the #Style and markup section with this:
“ |
In general, articles should use
wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme instead of the customary mauve, to tie in with the dominant colour in the series) but should not be used gratuitously.
Wikipedia articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features which would cause content to be hidden or corrupted when CSS and/or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content – which produces incomprehensible output without CSS – and some implementations of the NavFrame collapsing code – which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior. To accomodate these considerations, test any potentially-disruptive changes with JavaScript and/or CSS disabled. In Firefox, this can be done easily with the WebDeveloper extension; JavaScript can be disabled in IE in the 'Options' screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions. |
” |
Adding this to the #Tables section:
“ |
Scrolling and collapsible sections in tables or other block elements can be useful to save space and conceal at first-sight potentially superfluous information. However, such techniques must be used with caution, as this content can become inaccessible in a number of situations. Printers and screen-readers will both output only the content that is immediately visible on the page, and these structures are more likely to exhibit undesirable behavior on certain browsers. As such, these methods should not be used in the article body. This includes reference lists, image galleries, and image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler). Collapsible sections are useful in navboxes and infoboxes and are widely used outside the article namespace; in these instances, care should be taken to ensure that the content will still be acessible on devices which do not support JavaScript and/or CSS. |
” |
Integrating the resolution point is a bit trickier, there isn't really anywhere obvious to add it on to. I'd propose the following text, but am open to suggestions as to where to put it.
“ | Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 800x600; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally. | ” |
I think this covers most of my concerns; as I say, this is all standard practice already, so it's not instruction creep to codify it. Thoughts? Happy‑ melon 17:39, 25 January 2009 (UTC)
Hi. I'd like to suggest adopting the Gnome icon to represent accessibility issues in Wikipedia. Please discuss at the WikiProject. — Michael Z. 2009-01-25 19:17 z
Hi, in this article it says that earlier versions of JAWS can't read links in titles. How early? Are any of those versions still used? Spinach Monster ( talk) 20:12, 31 January 2009 (UTC)
I've raised on issue at WP:TIME where Andy has suggested I post here too. I've got red-green colour-blindness and I find some colours on the CIA World Factbook maps used on a number of timezone articles difficult to distinguish. For example, on the map File:Timezoneswest.PNG used in North_American_Central_Time_Zone, I find it hard to distinguish between the green and brown colours used for the two central time zones in North America. The caption where the image is including in the article contains a colour block which, to my eyesight, doesn't obviously match any of the colours on the map. Are people here able to provide guideines to the WP:TIME people on colour use and make changes themselves if necessary?-- Peter cohen ( talk) 00:51, 4 February 2009 (UTC)
17-Feb-2009: In the section named "Headings", the example-box showing 3 columns about Correct, Random or Skipping has been too wide to fit beside the infobox on 800x600 width windows. I suggest reducing to just 2 narrowed columns (total width=63%) as "Correct" & "Random/skipping" so that the narrowed box could fit beside the infobox on 800x600 resolution windows. See comparison below:
Wide box of 3 columns (version of 16-Feb-2009):
Correct | Random/chaotic | Skipping levels |
---|---|---|
|
|
|
Narrow box (proposed):
Correct | Random/skipping |
---|---|
[Article lead here]
|
[Article lead here]
|
People sometimes forget to test the appearance of tables using the 800x600 screen-width that was the majority of user-screens in 2005, so tables are often formatted as assuming people want to display in wide windows. By combining the examples of Random & Skipping (into a single column), those prior 2 columns can be reduced to 1 column. If there are no objections, I suggest replacing that 3-column table ASAP as 2-columns, by copying the 2-column table coding from inside this message. - Wikid77 ( talk) 10:28, 17 February 2009 (UTC)
Using the W3C WAI-ARIA suite link WAI ARIA Overview simplifies interaction for the blind and enhance keyboard navigation. To define landmarks/regions in the Wikipedia interface (MediaWiki) would enable user rapidly jump from one logical section to another. Furthermore an ARIA-based formatting toolbar in the editing page would simplify interaction via screen reader. Maribu2009 ( talk) 22:52, 18 February 2009 (UTC)
I think that transparent layers should not be used in wikipedia images as this mixes the content of an image with the colour of the web page. I browse the web with the browser and operating system set to white text on a black background, and this means that many images with transparent layers are unviewable. Also the keys to maps becomes invisible. Images would be accessible if they use the full colours that the images are supposed to represent instead of using transparent layers which rely on the web page background colour.
For discussion of this see: Wikipedia:Village pump (proposals)#Transparent backgrounds in images. Charvest ( talk) 17:44, 22 February 2009 (UTC)
In
WP:WikiProject Flag Template, we made sure that flag icon images (e.g. {{
flagicon|UK}}
to render
) have the alt attribute set, per
WP:Accessibility#Images. But is that actually desired? For example, I've seen comments where tables or lists such as:
are not good examples for accessibility because a screen reader will say "Flag of France France" and so on. Not being a screen reader user, is that the case? Is it any better if {{
flag}}
is used instead of {{
flagicon}}
, such as:
Looking for guidance on how these templates should render these icon images. Thanks — Andrwsc ( talk · contribs) 20:33, 25 February 2009 (UTC)
I just created a post that is of prime relevance to the issue of accessibility: Wikipedia_talk:WikiProject_Medicine#Medicalization. I would like to request other editors to come to this page and give their input into this topic. Cazort ( talk) 02:58, 1 March 2009 (UTC)
Just noticed that MOS:SCROLL claims to be the shortcut for WP:ACCESS#Scrolling and collapsible sections but actually links to Wikipedia:Manual of Style#Scrolling_lists. Which should it be? Am also posting this at WT:Manual of Style#MOS:SCROLL duplicated shortcut as I don't know where the best place for the discussion would be. cheers, Struway2 ( talk) 22:38, 3 March 2009 (UTC)
It has come to my attention that certain articles require the reader to "hover" over parts of an image to know what is pictured in it, as opposed to reading a caption, cf [8], [9]. Apparently this was achieved by stuffing the complex image map code into the latter part of the "name" parameter of the infobox, rather than as an image. I don't know why anyone would want to do this but it makes a mockery out of accessibility concerns. — CharlotteWebb 12:45, 22 March 2009 (UTC)
{{
Click}}
. But I bet it'd be hard to find the descriptions using screen magnification software, and there are probably other accessibility issues. But, like you, my main question is ... why would anyone want to do such a thing? It also should be implemented elegantly, not with a hack through the name field.
Graham
87 13:57, 22 March 2009 (UTC){{
Click}}
is accessible now. My main objections still stand though.
Graham
87 13:59, 22 March 2009 (UTC)
Hi. There's a discussion at Talk:Teitur Þórðarson over whether the article should be retitled Teitur Thordarson. I'm wondering about the accessibility aspect of this question. Thanks in advance for any reply. - GTBacchus( talk) 15:00, 28 March 2009 (UTC)
Recent experience indicates that I should preface this question with a disclaimer. What I am about to ask about, I do not consider to be a good idea. I seek technical knowledge of why it's not a good idea. Perhaps there is no technical reason, and the badness of the idea rests entirely on other grounds. That is what I wish to learn.
That said... Is there a specific accessibility issue regarding an image in an article that is placed in a toggle box, so that readers may toggle between two aspects of an image, such as "hide/show" or even something else? Would those pose any problem for screen readers, which presumably are already set up to handle images of the static variety? Thanks in advance for any information. :) - GTBacchus( talk) 15:16, 28 March 2009 (UTC)
I've been working on a mathematical article, Euclidean algorithm, and it's now at FAC. I think it's accessible, but I'd appreciate any suggestions for improving it. Thanks! Proteins ( talk) 17:35, 30 April 2009 (UTC)
Thanks, Graham, I'm glad you liked the article. By "proper headings", I guess you mean the places where I converted a subsubsection to the beginning of a definition list using a semicolon? I agree, and originally I wrote them as subsubsections. But I became aware of the FAC criterion that tables of contents must not be "overwhelming", and I was concerned that the article would be dinged for that reason. The FAC reviewers seem to take such matters seriously, so that's why there are now only sections and subsections. If the article passes, then I think we can restore the subsubsections without risking an FAR, far from the madding crowd. I'll also make an audio recording, although that won't have convenient navigational links. (Is that possible?)
Do you know of a list of HTML entities that aren't translated by JAWS? If so, I could go through the article and try to find substitutes. I'd like to keep Greek letters such as γ to suggest how different the quaternions are from everyday numbers (which I've depicted with upper- and lower-case Latin letters), but there are likely good alternatives, such as using boldface type or something. Your suggestions would be very welcome! Proteins ( talk) 15:17, 1 May 2009 (UTC)
I have only mild presbyopia as do most seniors. I have a lot of trouble with superscripts such as in m² and m³. These things appear in may articles. The authors of the {{ convert}} template were thoughtful enough to use HTML superscript like m2 and m3. I find this much easier to read. Though it means that many articles would need to be edited it is not an impossible task. A bot could do the job unattended. -- droll [chat] 19:25, 9 May 2009 (UTC)
Over at WP:CYC we are trying to establish a template for articles on races. A habit has emerged over using coloured backgrounds in tables to indicate holders of the various jerseys used to denote honours and competition leadership. See, for example 2008 Tour de France or 2008 Giro d'Italia, and especially the Jersey progress sections of each. I believe that we should indicate far more clearly a key for the significance of these colours, but I come here in search of your expertise on the suitability of these background colours for those with colour perception difficulties. If you give any observations here I will post them across to our discussions: if you wish to post directly, we have started the discussion at User_talk:Nosleep/Style_guide/Short_stage_race. Many thanks, Kevin McE ( talk) 06:55, 12 May 2009 (UTC)
Does using {{ flagicon}} in section headers compromise the accessibility of articles in any way? Refer to 2008 IIHF World Championship rosters. Dabomb87 ( talk) 23:52, 2 June 2009 (UTC)
The article currently says the minimum resolution should be 800x600 and from a discussion above and looking at the history, I see this was added relatively recently (January) with the claim it's the current consensus. While I respect that this was done with the best intentions, I have to disagree with it and the claim it has consensus. I have taken part in multiple discussion on this particularly with regard to the failed redesign of the main page and I've never seen any evidence for any real consensus other then the allegation made via poor sources that less then 1% of users have 640x480 (which ignores a wide variety of things like SDTVs with 720x576/720x480, resolutions of 800x600 without a maximised window, people using large text sizes meaning that even with a resolution of 800x600 or larger, the aiming for 800x600 could easily cause problems). More to the point, I've also seen no clear explaination or examples as to the harm of aiming for 640x480 as a minimum. If there's been some very wide reaching discussions that I've missed or if there are a large number of pages which don't work at 640x480 then I would be willing to accept it's a consensus that I've missed but if not, then I would dispute the notion there is any consensus and would suggest we bring this down to 640x480. As far as I'm aware, this is the resolution many pages, e.g. the current main page, set as their minimum during design and while this may be a while ago, I don't see any reason to change that without strong evidence for harm or necessity. Being VGA mode, it's also the minimum you're likely to use for the vast majority of normal displays, including old ones like 14 inch CRTs which may not be that uncommon in the developing world as well as should have some support with any resonable GUI. Nil Einne ( talk) 21:00, 3 June 2009 (UTC)
I've just been reading
List of Hannah Montana episodes and came across a template I've never seen used before: {{
explain}}
, a redirect to {{
tooltip}}
, used for explanatory text when the cursor hovers over the word. How does this works with JAWS and other screen readers on an ACCESS level, and also, wouldn't it be better to use explanitory footnotes instead?
Matthewedwards :
Chat 18:49, 6 June 2009 (UTC)
Should the Wikipedia featured article criteria require alt text for images? I've raised this issue in Wikipedia talk:Featured article candidates #Alt text in images; if you're interested, please follow up there. Eubulides ( talk) 23:01, 23 June 2009 (UTC)
FYI: Rules were recently added to MediaWiki:Print.css to expand boxes on printing; this of course does not apply to those that are classed as nonprintable such as navboxes. ---— Gadget850 (Ed) talk 11:30, 25 June 2009 (UTC)
Is the usage of images as symbols as seen at List of cardinal-nephews compliant with WP:ACCESS? Dabomb87 ( talk) 17:36, 3 July 2009 (UTC)
The tables in {{ Infobox Football biography}} need to be subdivided so that each line occupies its own table-row (examples: 'Senior career' and 'teams managed' in Andy Preece). I seem to recall a project specifically looking at such issues, can anyone tell me where that is, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:31, 23 July 2009 (UTC)
Somehow I ended up in a discussion at WP:IHC about potential "involuntary health consequences" from Wikipedia content. While I opposed that proposal, there does seem to be fairly widespread concern about the potential for flashing images with regularly spaced stripes to cause trouble in some viewers. The issue has previously been raised on this talk page at Wikipedia talk:Accessibility/Archive 1#Animated Picture of the Day, Wikipedia talk:Accessibility/Archive 1#Blinking text Wikipedia talk:Accessibility/Archive 4#Moving images, and Wikipedia talk:Accessibility/Archive 7#Animated image in essay. It is also discussed at [10]. I think it may be time for something to be written in the policy to reflect all this discussion.
Some of the images mentioned in those discussions include Image:Strobe.gif, Image:Tablet press animation.gif, File:Translational_motion.gif and Template:POTD_protected/2007-05-14. One of the most famous triggers for photosensitive epilepsy was the famous Dennō Senshi Porygon broadcast, for which animation is available at the article page.
The guidelines discussed in the archive are based on the Web Content Accessibility Guidelines against flashing text. This is referenced in the WP:IHC proposal as section 2.3.2 (AAA) [11], which says that no part of the Web page should flash more than three times. This is a stringent criterion that may exclude useful graphical illustrations for many articles. A much looser standard has been used by the British ITC (The Harding Test [12]) which restricts the percentage of the screen taken up by flashing patterns, especially those made up of regularly spaced lines.
My general feeling is that this can't really be solved with Wikipedia policy because most people who create these images won't have the faintest idea that they could be a problem. However, in fairness, accessibility guidelines could try to limit the hazards posed by the most troublesome images.
I'd like to propose an advisory guideline to be inserted just before "Keyboard shortcuts", which I've written in a non-binding way:
Photosensitive epilepsy
It has been reported that users with photosensitive epilepsy can use modern computer monitors set to a refresh rate of 75 Hz or above safely without risk of seizure. [1] Nonetheless, certain flashing images, particularly those containing regular patterns of lines, pose a risk to these viewers.
Those susceptible are strongly urged to take precautions on their own computers to protect themselves from such triggers. Some pages (such as Horse gait) display animations which play directly upon loading unless the user's Web browser settings prohibit it. Many potential editors will not think about epilepsy when adding animations to an article.
Web Content Accessibility Guidelines Section 2.3 discourages the use of text or images which flash between bright and dark values more than three times per second. Guidelines established for other media, such as the ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television, have advised caution when displaying regular striped patterns over more than 40% of the screen area or flashing striped patterns over 25% of the screen area. Wikipedia editors can improve the safety and accessibility of Wikipedia by considering these recommendations.
I welcome your comments. Mike Serfas ( talk) 02:14, 4 August 2009 (UTC)
There's an active discussion in Wikipedia talk:Featured article candidates about whether we should remove the requirement that featured articles have alt text to help visually impaired readers. In that discussion, please see the sections Alt text in images through Alt text for portraits, particularly the wording changes being proposed in Where things stand. I am interested in feedback about the claims in this discussion that alt text does not help visually impaired readers. Eubulides ( talk) 17:51, 5 August 2009 (UTC)
A recent edit added this text:
So I'm curious: what does a screen reader typically do when it's given text with unusual characters? Here are three examples: (1) "→"; (2) "^"; (3) "²".
Also, I don't agree with the proposal to replace "^" with an icon. Let's put it this way: the "^" is not an essential part of the article and doesn't need heavyweight support. Or another way: it's just as confusing for sighted readers as for the visually impaired, so there's no WP:ACCESSIBILITY argument for using an icon. Eubulides ( talk) 00:28, 22 August 2009 (UTC)
title
attributes in links. But be aware that assistive technology is in development, and improves as demand expand. So provinding title
attributes in links is not a bad idea at all. See
H33: Supplementing link text with the title attribute, techniques for WCAG 2.0.Just for informational purposes, my wife, who has a severe visual impairment, uses a screen enlargement/reader combination program called ZoomText. In its current configuration, it ignores unicode entirely when in screen-reading mode. - Dewelar ( talk) 00:21, 23 August 2009 (UTC)
Following up on the above discussion, I added two sections to the alt text guidelines. WP:ALT#Math discusses math formulas and follows Graham's suggestion in saying that simple formulas are an easy case for alt text, whereas complex ones may be better rendered as the LaTeX. As it happens, if you don't specify alt text for a math formula, it defaults to the LaTeX, so that simplifies matters. WP:ALT#Text discusses images containing prominent text, Unicode, etc. I had the most fun writing the suggestion that alt text say "Spiral staircase" rather than "꩜ ▁▂▃▄▅▆▇█"; that latter quote is valid Unicode but it doesn't even render correctly on my browser, which is the latest Firefox. Further comments here (or at WT:ALT) are welcome. Eubulides ( talk) 17:10, 31 August 2009 (UTC)
How might we improve the accessibility of pages like Common year starting on Saturday? Leap year starting on Sunday which uses {{ Year3}}, seems better, but barely so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:03, 31 August 2009 (UTC)
Mo | Tu | We | Th | Fr | Sa | Su | |
---|---|---|---|---|---|---|---|
Week 1 | 1 | 2 | |||||
Week 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
Week 3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
Week 4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
Week 5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Week 6 | 31 |
<abbr>
elements for the day-names?
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 14:38, 31 August 2009 (UTC)
abbr
should be an attribute of the th
element, no? That is, "<th abbr="Monday"...>Mo</th>
". Second, those "Week 1" row headers are a big distraction to the sighted reader; shouldn't they be made invisible?
Eubulides (
talk) 17:19, 31 August 2009 (UTC)
← Visually, this may be better:
Week | Mo | Tu | We | Th | Fr | Sa | Su |
---|---|---|---|---|---|---|---|
1 | 1 | 2 | |||||
2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
6 | 31 |
abbr
element is now implemented in MediaWiki!Week | Mo | Tu | We | Th | Fr | Sa | Su |
---|---|---|---|---|---|---|---|
1 | 1 | 2 | |||||
2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
6 | 31 |
The abbr
element was implemented in the
last MediaWIki update! That's great news See
bugzilla:671, the community was asking fot that element since 2004. So I just made a new table using the abbr
element. See
H28: Providing definitions for abbreviations by using the abbr and acronym elements, Techniques for WCAG 2.0, W3C for further information.
By the way, the abbr
attribute in a td
element does the opposite of the abbr
element : it is made to display an abreviation of a long header content to the screen reader. "When table header content is repeatedly rendered by the user agent, the content of the abbr
attribute should be rendered in place of table header content." See
the ABBR attribute for TH elements, WAI, W3C for further details on how to use it. Yours,
Dodoïste (
talk) 20:43, 28 September 2009 (UTC)
<abbr>
instead of a Wikilink. That is, "{{circa|1100}}
" used to output "
c. 1100"; now it outputs "
c. 1100". This is better for sighted readers as it uses the more-common mechanism for abbreviations; I hope it's OK accessibility-wise.
Eubulides (
talk) 16:34, 29 September 2009 (UTC)
Please see and comment. Thanks, – xeno talk 14:55, 31 August 2009 (UTC)
Please clarify at [13]. Thanks, Dabomb87 ( talk) 13:32, 13 September 2009 (UTC)
Is it a problem to use images in section headers, such as Wikipedia:WikiProject Lancashire and Cumbria? Dabomb87 ( talk) 22:11, 16 September 2009 (UTC)
|link=
as per
WP:ALT #Purely decorative images. I
did that. I don't see an accessibility issue once this is done. You might want to let other projects know about |link=
, if they use this style.
Eubulides (
talk) 22:36, 16 September 2009 (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 8 | Archive 9 | Archive 10 | Archive 11 | Archive 12 | → | Archive 15 |
What do people think of Family of Barack Obama ? Andy Mabbett | Talk to Andy Mabbett 22:43, 26 August 2008 (UTC)
[outdent] Accessibility isn't (at least not in this case) about complexity; this is the equivalent of drawing the family tree on paper, then placing it face-down and expecting someone to read it. If you can (and are sighted), view an instance of the template, in Firefox, using the "web Developer" toolbar with "miscellaneous - linerarize page" activated. Even after teh removal of huge anmuonts of white space, it looks like:
Elimelech Naomi Boaz Ruth Mahlon Orpah Chilion Obed Jesse David
See also Wikipedia:Accessibility#Layout tables
Folks,
I have had a go at an entirely different approach to drawing family trees.
If I could trouble you to have a look at User:Pee Tern/Sandbox/Template/Family tree chart/doc please ?
What do people think ?
Initial comments / suggestions / issues, here, please before I do much more work on it.
Also, for example, would "display:none;"s to give hidden column and row headings help ?
Please note that while definitely in the direction I think it should be going, it is still very much a work in progress !
Peet Ern ( talk) 12:45, 11 December 2008 (UTC)
← I think the semantically-correct and more accessible way to do this may be via nested lists, with suitable styling, of course. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:10, 13 December 2008 (UTC)
I made a version of a Barack Obama family tree here. Any thoughts? ~ Richmond96 t • c 03:22, 15 December 2008 (UTC)
the template {{
flatlist}} and its partner {{
endflatlist}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than characters which are read out ("one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. Example
Andy Mabbett |
Talk to Andy Mabbett 20:43, 28 August 2008 (UTC)
The use of a vertical bar character (or CSS equivalent) in place of the bullet character is not acceptable as the bar produced is not perfectly vertical and causes problems reading the lists as you go cross-eyed when there are short entries between the bars. The CSS mark-up needs to produce an unobtrusive character similar to the bullet when applied to lists. Keith D ( talk) 22:49, 5 September 2008 (UTC)
← "Long-standing consensus" can - and where it is harmful, should - be challenged. That said, I'm not insisting on the use of vertical-bar separators, and I don't know anyone else who is. I have already proposed two methods of using dot-shaped separators via CSS, and I've invited others to contribute alternatives. I am fully aware that accessibility is not just about blind users, or have I ever said or suggested such. Users using Braille display might not feel CSS separators; but who to they feel dot characters? How are lists rendered to them overall? Have you asked blind users whether they want to hear the word "dot" fifty or more tines as a separator? I have, and those users of audio browsers I have discussed the matter with most certainly do not. WCAG 1.0 tells us:
3.6 Mark up lists and list items properly. [Priority 2]
For example, in HTML, nest OL, UL, and DL lists properly. [1]
If you have evidence that WCAG is wrong, please cite it. The fact remains that - despite your unsupported assertion to the contrary - using in-line graphical characters as separators presents an accessibility barrier to some users and that marking up lists using in-line graphical characters, without using UL
or OL
and LI
elements, is semantic nonsense.
Andy Mabbett (User:Pigsonthewing);
Talk to Andy Mabbett;
Andy Mabbett's contributions 13:02, 6 September 2008 (UTC)
While I'm here...Pigonthewing's edits don't look right. "=" headings are not used, and WP:MOS already has guidance on how to nest subheadings; it's probably best not to do that in two places. Unless someone knows different, I'll revert. - Dan Dank55 ( send/receive) 20:53, 30 August 2008 (UTC)
A quick check shows the heading structure on every page to be broken, in the Wikipedia template (and thus outside the control of ordinary editors) - there is an H1 (the page title) immediately followed by an H3 ("From Wikipedia, the free encyclopedia"); and the page ends with a bunch of H5s ("Views", "Personal tools", "Navigation", "Search", "Interaction", "Toolbox") with no parent other than H1 (and the last headings in the article, which are not meant to apply to it). I raise this elsewhere, as soon as I have time. Andy Mabbett | Talk to Andy Mabbett 09:24, 31 August 2008 (UTC)
←How would you like to fix the heading structure on every page, and will the reader notice any difference? - Dan Dank55 ( send/receive) 16:18, 31 August 2008 (UTC)
Further info: WCAG says:
3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. ( [2])
and:
Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. ( [3])
On further reflection, "From Wikipedia, the free encyclopedia" isn't even a heading, and should probably be marked up as a paragraph. Andy Mabbett | Talk to Andy Mabbett 16:50, 31 August 2008 (UTC)
←
— SMcCandlish [ talk] [ cont] ‹(-¿-)› 21:03, 31 August 2008 (UTC)
Pigs, I see that you've cited a non-Wikipedia source as your authority. The Wikimedia software apparently doesn't comply with this outside group's rules. What I want to know is what practical difference does it make for a disabled person? Imagine a page skips from Level 1 to Level 3 with no intervening Level 2 header. What problem does this create? Do the screen readers quit reading? WhatamIdoing ( talk) 21:23, 31 August 2008 (UTC)
Okay, so, aside from WhatamIdoing simply not believing what he's being told, that this addresses well-known and well-understood accessibility issues, the real question is where to put this? I'd be somewhat in favor of moving it to a more general guideline ( WP:LAYOUT seems like a likely target) and referencing that from here. By having it in the more general guideline, both the accessibility and semantic web issues can be mentioned without either sounding out-of-place — SMcCandlish [ talk] [ cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)
Please see Template talk:Documentation#Heading fix. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:27, 8 September 2008 (UTC)
Simple succession boxes (like the second one here), seem OK, though they do lack headers, but complex cases, like this hypothetical example on the template documentation page, seem less so. Thoughts? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:54, 2 September 2008 (UTC)
←Thank you for a detailed response. Please bear in mind that the accessibility discussed here is specifically for people with a disability or other condition which can mean that their use of Wikipedia is not conducted in the same way, or using the same tools, as most of us use. That can include people who cannot see, and who have the pages read out loud to them by their computer. For such users, tables (which is how succession boxes are rendered), when used for layout rather than for tabular data, can be very problematic, because the software reads across rows; and because there is no header row or column to label the others. If you have Firefox, this effect can be simulated by using the "web Developer" extension, then selecting "Miscellaneous" then "Linearize Page". The table on Winston Churchill, while not perfect, and very long, is better than many, because it consists of simple rows. When, like in the hypothetical example discussed above, the first cell in a row covers multiple cells in the remaining columns, its accessibility is reduced. In that case, it can be read, in part, in the order:
and so on.
Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:18, 6 September 2008 (UTC)
I have just noticed this:
* Images now take their alt text from their alt= parameter, if one is present. ( r41837, bug 368)
in the Signpost archives. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:46, 23 November 2008 (UTC)
OK, it sounds as though we're getting a consensus, although we should probably wait a week or so to let others chime in. Maybe we should also post a public message about the need for alt text, and that we're considering an addition to the accessibility guidelines? Once everyone's on board, we should contact the FA authors, which we can maybe do by working our way down WP:WBFAN. As you say, L'Aquatique, there's no rush but it'd also be a nice gesture. When we start adding them ourselves, I'm probably best suited for math-y and science articles, but I'll volunteer for anything.
I just noticed something odd. I'm not sure how long it's been going on, but my screen readers no longer read the caption twice. I've been tinkering with settings, so that might've done the trick, or it might be part of the bugfix that Andy mentioned. Are others having the same experience? I'm inclined towards the latter explanation, because I seem to remember that the caption was repeated in the image alt text, if you looked at the HTML source. That's how I'd been explaining to myself why screen readers read the caption twice: once for the alt text and once for the caption itself. But now the alt text seems to be an empty string unless you specify one. Proteins ( talk) 14:37, 27 November 2008 (UTC)
Not having heard any opposition, I think we should be bold and add a requirement for alt text to the WP:ACCESS guidelines. To help people with that, perhaps we should update these instructions on writing good alt text for equations and images? Most editors will be unfamiliar with it, as I was, and we should make their learning curve as quick and easy as possible. I'll do my best with that, but most people here will know more than me — help would be appreciated! Proteins ( talk) 14:17, 5 December 2008 (UTC)
I updated WP:ACCESS and MOS:IMAGES as best I could, but please check them over. I also re-wrote the leads to WP:ALT and WP:CAP, but not yet their bodies. I wrote this script to check whether the images on a page have alt text. Longer-term, we should also think about updating pages such as
but perhaps it'd be wiser to see how this initial round of edits goes over. Once the idea of image alt text has had a chance to percolate through Wikipedia and once the guidelines are worked out, it should be safe to contact people at WT:FA, WP:WBFAN and WP:WPM to make their works more accessible. Proteins ( talk) 17:44, 5 December 2008 (UTC)
I have a query about the following guideline: "Images should be inside the section they belong to (after the header and after any links to other articles), and not just before the header." Is there any specific accessibility reason for this? Wikipedia:Manual of Style advises that editors should not "place left-aligned images directly below subsection-level (=== or greater) headings, as this can disconnect the heading from the text it precedes. This can often be avoided by shifting left-aligned images down a paragraph or two." However, sometimes for aesthetic reasons it seems better to place the image just before the subsection heading so that the heading and the text are in line. For example, if the subsection is short and has, say, only two or three paragraphs, placing the image lower down in the subsection can cause it to extend into the next section and create text alignment problems. — Cheers, JackLee – talk– 17:23, 27 November 2008 (UTC)
Wouldn't the caption or text tip be sufficient to provide the necessary context, though, since the very next bit of text would be the subsection heading anyway? I'm just wondering whether the guideline ought to be so rigid. It seems to me that there isn't much difference if the image caption is read just before the subheading, or the subheading is read just before the image caption by a screen reader. — Cheers, JackLee – talk– 07:01, 28 November 2008 (UTC)
Thanks for the clarification. I asked because another editor relocated an image in an article on the basis of compliance with this guideline. I didn't think that the change was really necessary, but didn't object to it. Nonetheless, I wanted to find out the rationale behind the guideline. Yes, other views on the matter are most welcome. — Cheers, JackLee – talk– 07:52, 28 November 2008 (UTC)
Perhaps, then, we should do away with the guideline stating that images should not be placed immediately after subsection-level headings. That rule and the rule regarding keeping images within sections place editors between a rock and a hard place when the subsection in question is short. — Cheers, JackLee – talk– 10:22, 28 November 2008 (UTC)
Seeing how this was in response to an edit I made, I would have appreciated a note informing me of this discussion, but that's okay. I don't know enough about screen readers to make a comment about it, so I'll trust whatever Graham87 says. I made the edits in question for two simple reasons: Images should go in the most relevant section. Suppose there was the section "Style B" and an image of this style. The image should be within this section and not right above it in section "Style A". It's really simple: images should go in the section they are relevant to, not right above the section in a different, irrelevant section. If you want to edit the image and text of the same topic, they shouldn't be in different edit sections.
Second, it looks better. Images shouldn't be to the side of a header yet both above and below it; it just looks really bad, especially when there's extra white space below it.
I see the problem of having a left-aligned image right under a 3rd level heading, but I don't personally care. The image is still in the correct relevant section, and the header, although separate from the text, is on top of the image. That isn't a big deal for me, but images really need to be in their relevant section, not right above. Reywas92 Talk 17:37, 28 November 2008 (UTC)
Phil, on my fairly standard screen using Firefox, this image obscures the edit button, so that's no good. I've played around with the CSS before, and it's frustrating; there are various codes that give me exactly what I want in the preview, but then obscure the edit button on the saved page.
Here's what we get when the image wikilink comes just before the subsection heading. Note the edit button is pushed just to the left of the image. - Dan Dank55 ( send/receive) 22:01, 28 November 2008 (UTC)
Someone recently edited a dab page to remove {{ TOCright}}, with an edit summary consisting of just " WP:ACCESS".
In reading this page, it says "Avoid floating the table of contents if possible," which seems like less of a prohibition than just a quick and maybemisleading summary of the linked-to section on Floating the TOC, which includes the line:
- A left-floated TOC may affect bulleted or numbered lists. Where it does, float the TOC to the right, or do not float it.
Dab pages follow different formatting rules than articles in any event; floating or suppressing the TOC is common practice, as the TOC doesn't really do a whole lot of good, and does disrupt the list flow.
Is there existing consensus on how TOCs should be handled on a dab page to accommodate both accessibility and general usability? Thanks, NapoliRoma ( talk) 17:21, 3 December 2008 (UTC)
Version 2.0 of the W3C's Web Content Accessibility Guidelines is now finished (see W3C Recommendation 11 December 2008; press release). It's very different to v1.0.
There is still no clear written policy (leastwise, none that I can find) mandating or recommending that those industry-standard guidelines should be followed, let alone to which level, on Wikipedia. I believe that there should be a clear policy that WCAG guidelines should be followed to a stated level; or at least that we should, as a body, strive towards doing so.
Does anyone have comments, and would people support such a move, and be willing to assist me in taking it forward? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:35, 13 December 2008 (UTC)
I'm not highly active here and I'm not presuming to give anyone advice. I have put off familiarizing myself with WCAG 2 until it was finalized, and I have just started to read about it. It is very large, and will take some time to understand. So personally, I won't commit to supporting it yet.
I have a reasonable understanding of WCAG 1 and the Samurai Errata, and I am comfortable working with them now. It is still possible to conform to 1.0, or both 1 and 2:
WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.
To this point we (en.Wikipedia) haven't officially committed to meeting any particular level of accessibility conformance (right?). I'd feel more comfortable launching an effort to evaluate articles' conformance levels—following any or all of these guidelines—as a way to gauge and improve accessibility. — Michael Z. 2009-01-06 06:20 z
So let me begin with these two questions (or set of questions in the latter case):
Having waded through part of WCAG 2, my recommendation is that we pretend it doesn't exist. The guidelines suffer from a bad case of second-system syndrome, and the authors don't seem to understand the boundaries between a webpage and the user-agent rendering the webpage: there are a number of guidelines where you can't say a webpage meets the guideline, you can only say that it doesn't actively interfere with meeting the guideline. -- Carnildo ( talk) 04:55, 9 January 2009 (UTC)
How does the main table in ISO 3166-2:GB render, in a screen-reader? Badly, I suspect, If so, we will need to find a better method for laying out the table (which currently has two lots of the same information, sorted differently), then ask for a bot to apply it to the many similar articles (see navbox at the foot of that page), one for each country. Would a simple, sortable table suffice? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:12, 14 December 2008 (UTC)
Template talk:Xt#Accessibility could use a third opinion about accessibility for this template. Thanks. — Michael Z. 2008-12-31 22:48 z
The "Images" section of this page states that images should have alt text (1) and that images should have captions (2). This gives me the impression that every image should have both alt text and a caption. At
Wikipedia:Alternative text for images, it is stated, "Every image, including math-mode equations, should specify alternative text (alt text)", but then there is an entire section called "When alternative text is unnecessary", which says "Alternative text may not be necessary if the caption itself suffices to describe the image". So now it appears a caption may warrant removal of alt text. Then at
Wikipedia:Captions, we have, "Not every Wikipedia image needs a caption" and "Regardless of whether you include a caption, all images should have alt text", so now maybe we can have alt text but no caption. Furthermore, many infoboxes such as {{
Infobox VG}} have a "caption" parameter that displays text under the image (specified with the "image" parameter)—is this a separate case from a caption given in the [[Image:...|caption]]
format, or is a caption a caption? I try to follow accessibility rules when I can, but this is extremely confusing and I would appreciate it if someone who is knowledgeable in this area can get these pages in sync so editors like me can tell what we're supposed to do.
Pagra
shtak 21:17, 2 January 2009 (UTC)
Wikipedia has a checklist called " The perfect article".
Here is a discussion on whether or not an inaccessible article can be called "perfect", where it has been suggested that WCAG guidelines "aren't appropriate for Wikipedia". Please feel free to contribute. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:37, 3 January 2009 (UTC)
Talk:Alexander Alekhine#Hidden solutions in diagrams: a number of articles on chess players and chess tactics include 'problems', where a chessboard is shown midway through a game, there being an optimal set of moves for one or other side thereafter. The captions on these pseudo-images include the sequence of moves, but hidden inside collapsible sections ( eg). I removed the hidden styling citing both accessibility and 'not censored' concerns, but was reverted. Comments are appreciated. Happy‑ melon 21:35, 6 January 2009 (UTC)
There's a discussion at Template talk:Infobox Weather#This template or template:Climate_chart about the use of {{ Infobox Weather}} vs. {{ Climate chart}} which both present the same kind of data but in completely different formats (one is a table of numbers with different color backgrounds to indicate coldness to hotness where the other is a bar chart). If there are accessibility reasons one of these should be preferred over the other please comment (there, not here). Thanks. -- Rick Block ( talk) 03:35, 9 January 2009 (UTC)
Hi, do the scrolling box things (see here) cause accessibility problems? Thanks Ling.Nut ( talk— WP:3IAR) 05:22, 14 January 2009 (UTC)
One thing I do like about WCAG 2 is that its Conformance section is very specific (although a bit complex). Before we can evaluate specific articles, we need to determine the baseline provided by the WikiMedia software, and its implementation in Wikipedia, and set some goals.
Checklists are available for WCAG 1 (sorted by priority), [6] and WCAG 2. [7]. — Michael Z. 2009-01-18 07:36 z
Are screen resolution and browsers without JavaScript. As far as I'm aware, the current consensus is that our pages should look acceptable on 800x600 (but no lower) and that all content should be accessible to users without JavaScript and CSS, although it is accepted that it may look inferior. However, these guidelines are not really laid out anywhere properly, this page seems the natural place to do so. This ties in well with MOS:SCROLL, which has always seemed rather out-of-place to me on the main MoS page when it's largely an accessibility issue. If that section were moved here (and the shortcut updated) it could be made clearer and more extensive without bulking up the main MoS page.
Largely to kickstart some discussion, I'll throw out some proposed wording. How about replacing the #Style and markup section with this:
“ |
In general, articles should use
wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme instead of the customary mauve, to tie in with the dominant colour in the series) but should not be used gratuitously.
Wikipedia articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features which would cause content to be hidden or corrupted when CSS and/or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content – which produces incomprehensible output without CSS – and some implementations of the NavFrame collapsing code – which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior. To accomodate these considerations, test any potentially-disruptive changes with JavaScript and/or CSS disabled. In Firefox, this can be done easily with the WebDeveloper extension; JavaScript can be disabled in IE in the 'Options' screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions. |
” |
Adding this to the #Tables section:
“ |
Scrolling and collapsible sections in tables or other block elements can be useful to save space and conceal at first-sight potentially superfluous information. However, such techniques must be used with caution, as this content can become inaccessible in a number of situations. Printers and screen-readers will both output only the content that is immediately visible on the page, and these structures are more likely to exhibit undesirable behavior on certain browsers. As such, these methods should not be used in the article body. This includes reference lists, image galleries, and image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler). Collapsible sections are useful in navboxes and infoboxes and are widely used outside the article namespace; in these instances, care should be taken to ensure that the content will still be acessible on devices which do not support JavaScript and/or CSS. |
” |
Integrating the resolution point is a bit trickier, there isn't really anywhere obvious to add it on to. I'd propose the following text, but am open to suggestions as to where to put it.
“ | Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 800x600; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally. | ” |
I think this covers most of my concerns; as I say, this is all standard practice already, so it's not instruction creep to codify it. Thoughts? Happy‑ melon 17:39, 25 January 2009 (UTC)
Hi. I'd like to suggest adopting the Gnome icon to represent accessibility issues in Wikipedia. Please discuss at the WikiProject. — Michael Z. 2009-01-25 19:17 z
Hi, in this article it says that earlier versions of JAWS can't read links in titles. How early? Are any of those versions still used? Spinach Monster ( talk) 20:12, 31 January 2009 (UTC)
I've raised on issue at WP:TIME where Andy has suggested I post here too. I've got red-green colour-blindness and I find some colours on the CIA World Factbook maps used on a number of timezone articles difficult to distinguish. For example, on the map File:Timezoneswest.PNG used in North_American_Central_Time_Zone, I find it hard to distinguish between the green and brown colours used for the two central time zones in North America. The caption where the image is including in the article contains a colour block which, to my eyesight, doesn't obviously match any of the colours on the map. Are people here able to provide guideines to the WP:TIME people on colour use and make changes themselves if necessary?-- Peter cohen ( talk) 00:51, 4 February 2009 (UTC)
17-Feb-2009: In the section named "Headings", the example-box showing 3 columns about Correct, Random or Skipping has been too wide to fit beside the infobox on 800x600 width windows. I suggest reducing to just 2 narrowed columns (total width=63%) as "Correct" & "Random/skipping" so that the narrowed box could fit beside the infobox on 800x600 resolution windows. See comparison below:
Wide box of 3 columns (version of 16-Feb-2009):
Correct | Random/chaotic | Skipping levels |
---|---|---|
|
|
|
Narrow box (proposed):
Correct | Random/skipping |
---|---|
[Article lead here]
|
[Article lead here]
|
People sometimes forget to test the appearance of tables using the 800x600 screen-width that was the majority of user-screens in 2005, so tables are often formatted as assuming people want to display in wide windows. By combining the examples of Random & Skipping (into a single column), those prior 2 columns can be reduced to 1 column. If there are no objections, I suggest replacing that 3-column table ASAP as 2-columns, by copying the 2-column table coding from inside this message. - Wikid77 ( talk) 10:28, 17 February 2009 (UTC)
Using the W3C WAI-ARIA suite link WAI ARIA Overview simplifies interaction for the blind and enhance keyboard navigation. To define landmarks/regions in the Wikipedia interface (MediaWiki) would enable user rapidly jump from one logical section to another. Furthermore an ARIA-based formatting toolbar in the editing page would simplify interaction via screen reader. Maribu2009 ( talk) 22:52, 18 February 2009 (UTC)
I think that transparent layers should not be used in wikipedia images as this mixes the content of an image with the colour of the web page. I browse the web with the browser and operating system set to white text on a black background, and this means that many images with transparent layers are unviewable. Also the keys to maps becomes invisible. Images would be accessible if they use the full colours that the images are supposed to represent instead of using transparent layers which rely on the web page background colour.
For discussion of this see: Wikipedia:Village pump (proposals)#Transparent backgrounds in images. Charvest ( talk) 17:44, 22 February 2009 (UTC)
In
WP:WikiProject Flag Template, we made sure that flag icon images (e.g. {{
flagicon|UK}}
to render
) have the alt attribute set, per
WP:Accessibility#Images. But is that actually desired? For example, I've seen comments where tables or lists such as:
are not good examples for accessibility because a screen reader will say "Flag of France France" and so on. Not being a screen reader user, is that the case? Is it any better if {{
flag}}
is used instead of {{
flagicon}}
, such as:
Looking for guidance on how these templates should render these icon images. Thanks — Andrwsc ( talk · contribs) 20:33, 25 February 2009 (UTC)
I just created a post that is of prime relevance to the issue of accessibility: Wikipedia_talk:WikiProject_Medicine#Medicalization. I would like to request other editors to come to this page and give their input into this topic. Cazort ( talk) 02:58, 1 March 2009 (UTC)
Just noticed that MOS:SCROLL claims to be the shortcut for WP:ACCESS#Scrolling and collapsible sections but actually links to Wikipedia:Manual of Style#Scrolling_lists. Which should it be? Am also posting this at WT:Manual of Style#MOS:SCROLL duplicated shortcut as I don't know where the best place for the discussion would be. cheers, Struway2 ( talk) 22:38, 3 March 2009 (UTC)
It has come to my attention that certain articles require the reader to "hover" over parts of an image to know what is pictured in it, as opposed to reading a caption, cf [8], [9]. Apparently this was achieved by stuffing the complex image map code into the latter part of the "name" parameter of the infobox, rather than as an image. I don't know why anyone would want to do this but it makes a mockery out of accessibility concerns. — CharlotteWebb 12:45, 22 March 2009 (UTC)
{{
Click}}
. But I bet it'd be hard to find the descriptions using screen magnification software, and there are probably other accessibility issues. But, like you, my main question is ... why would anyone want to do such a thing? It also should be implemented elegantly, not with a hack through the name field.
Graham
87 13:57, 22 March 2009 (UTC){{
Click}}
is accessible now. My main objections still stand though.
Graham
87 13:59, 22 March 2009 (UTC)
Hi. There's a discussion at Talk:Teitur Þórðarson over whether the article should be retitled Teitur Thordarson. I'm wondering about the accessibility aspect of this question. Thanks in advance for any reply. - GTBacchus( talk) 15:00, 28 March 2009 (UTC)
Recent experience indicates that I should preface this question with a disclaimer. What I am about to ask about, I do not consider to be a good idea. I seek technical knowledge of why it's not a good idea. Perhaps there is no technical reason, and the badness of the idea rests entirely on other grounds. That is what I wish to learn.
That said... Is there a specific accessibility issue regarding an image in an article that is placed in a toggle box, so that readers may toggle between two aspects of an image, such as "hide/show" or even something else? Would those pose any problem for screen readers, which presumably are already set up to handle images of the static variety? Thanks in advance for any information. :) - GTBacchus( talk) 15:16, 28 March 2009 (UTC)
I've been working on a mathematical article, Euclidean algorithm, and it's now at FAC. I think it's accessible, but I'd appreciate any suggestions for improving it. Thanks! Proteins ( talk) 17:35, 30 April 2009 (UTC)
Thanks, Graham, I'm glad you liked the article. By "proper headings", I guess you mean the places where I converted a subsubsection to the beginning of a definition list using a semicolon? I agree, and originally I wrote them as subsubsections. But I became aware of the FAC criterion that tables of contents must not be "overwhelming", and I was concerned that the article would be dinged for that reason. The FAC reviewers seem to take such matters seriously, so that's why there are now only sections and subsections. If the article passes, then I think we can restore the subsubsections without risking an FAR, far from the madding crowd. I'll also make an audio recording, although that won't have convenient navigational links. (Is that possible?)
Do you know of a list of HTML entities that aren't translated by JAWS? If so, I could go through the article and try to find substitutes. I'd like to keep Greek letters such as γ to suggest how different the quaternions are from everyday numbers (which I've depicted with upper- and lower-case Latin letters), but there are likely good alternatives, such as using boldface type or something. Your suggestions would be very welcome! Proteins ( talk) 15:17, 1 May 2009 (UTC)
I have only mild presbyopia as do most seniors. I have a lot of trouble with superscripts such as in m² and m³. These things appear in may articles. The authors of the {{ convert}} template were thoughtful enough to use HTML superscript like m2 and m3. I find this much easier to read. Though it means that many articles would need to be edited it is not an impossible task. A bot could do the job unattended. -- droll [chat] 19:25, 9 May 2009 (UTC)
Over at WP:CYC we are trying to establish a template for articles on races. A habit has emerged over using coloured backgrounds in tables to indicate holders of the various jerseys used to denote honours and competition leadership. See, for example 2008 Tour de France or 2008 Giro d'Italia, and especially the Jersey progress sections of each. I believe that we should indicate far more clearly a key for the significance of these colours, but I come here in search of your expertise on the suitability of these background colours for those with colour perception difficulties. If you give any observations here I will post them across to our discussions: if you wish to post directly, we have started the discussion at User_talk:Nosleep/Style_guide/Short_stage_race. Many thanks, Kevin McE ( talk) 06:55, 12 May 2009 (UTC)
Does using {{ flagicon}} in section headers compromise the accessibility of articles in any way? Refer to 2008 IIHF World Championship rosters. Dabomb87 ( talk) 23:52, 2 June 2009 (UTC)
The article currently says the minimum resolution should be 800x600 and from a discussion above and looking at the history, I see this was added relatively recently (January) with the claim it's the current consensus. While I respect that this was done with the best intentions, I have to disagree with it and the claim it has consensus. I have taken part in multiple discussion on this particularly with regard to the failed redesign of the main page and I've never seen any evidence for any real consensus other then the allegation made via poor sources that less then 1% of users have 640x480 (which ignores a wide variety of things like SDTVs with 720x576/720x480, resolutions of 800x600 without a maximised window, people using large text sizes meaning that even with a resolution of 800x600 or larger, the aiming for 800x600 could easily cause problems). More to the point, I've also seen no clear explaination or examples as to the harm of aiming for 640x480 as a minimum. If there's been some very wide reaching discussions that I've missed or if there are a large number of pages which don't work at 640x480 then I would be willing to accept it's a consensus that I've missed but if not, then I would dispute the notion there is any consensus and would suggest we bring this down to 640x480. As far as I'm aware, this is the resolution many pages, e.g. the current main page, set as their minimum during design and while this may be a while ago, I don't see any reason to change that without strong evidence for harm or necessity. Being VGA mode, it's also the minimum you're likely to use for the vast majority of normal displays, including old ones like 14 inch CRTs which may not be that uncommon in the developing world as well as should have some support with any resonable GUI. Nil Einne ( talk) 21:00, 3 June 2009 (UTC)
I've just been reading
List of Hannah Montana episodes and came across a template I've never seen used before: {{
explain}}
, a redirect to {{
tooltip}}
, used for explanatory text when the cursor hovers over the word. How does this works with JAWS and other screen readers on an ACCESS level, and also, wouldn't it be better to use explanitory footnotes instead?
Matthewedwards :
Chat 18:49, 6 June 2009 (UTC)
Should the Wikipedia featured article criteria require alt text for images? I've raised this issue in Wikipedia talk:Featured article candidates #Alt text in images; if you're interested, please follow up there. Eubulides ( talk) 23:01, 23 June 2009 (UTC)
FYI: Rules were recently added to MediaWiki:Print.css to expand boxes on printing; this of course does not apply to those that are classed as nonprintable such as navboxes. ---— Gadget850 (Ed) talk 11:30, 25 June 2009 (UTC)
Is the usage of images as symbols as seen at List of cardinal-nephews compliant with WP:ACCESS? Dabomb87 ( talk) 17:36, 3 July 2009 (UTC)
The tables in {{ Infobox Football biography}} need to be subdivided so that each line occupies its own table-row (examples: 'Senior career' and 'teams managed' in Andy Preece). I seem to recall a project specifically looking at such issues, can anyone tell me where that is, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:31, 23 July 2009 (UTC)
Somehow I ended up in a discussion at WP:IHC about potential "involuntary health consequences" from Wikipedia content. While I opposed that proposal, there does seem to be fairly widespread concern about the potential for flashing images with regularly spaced stripes to cause trouble in some viewers. The issue has previously been raised on this talk page at Wikipedia talk:Accessibility/Archive 1#Animated Picture of the Day, Wikipedia talk:Accessibility/Archive 1#Blinking text Wikipedia talk:Accessibility/Archive 4#Moving images, and Wikipedia talk:Accessibility/Archive 7#Animated image in essay. It is also discussed at [10]. I think it may be time for something to be written in the policy to reflect all this discussion.
Some of the images mentioned in those discussions include Image:Strobe.gif, Image:Tablet press animation.gif, File:Translational_motion.gif and Template:POTD_protected/2007-05-14. One of the most famous triggers for photosensitive epilepsy was the famous Dennō Senshi Porygon broadcast, for which animation is available at the article page.
The guidelines discussed in the archive are based on the Web Content Accessibility Guidelines against flashing text. This is referenced in the WP:IHC proposal as section 2.3.2 (AAA) [11], which says that no part of the Web page should flash more than three times. This is a stringent criterion that may exclude useful graphical illustrations for many articles. A much looser standard has been used by the British ITC (The Harding Test [12]) which restricts the percentage of the screen taken up by flashing patterns, especially those made up of regularly spaced lines.
My general feeling is that this can't really be solved with Wikipedia policy because most people who create these images won't have the faintest idea that they could be a problem. However, in fairness, accessibility guidelines could try to limit the hazards posed by the most troublesome images.
I'd like to propose an advisory guideline to be inserted just before "Keyboard shortcuts", which I've written in a non-binding way:
Photosensitive epilepsy
It has been reported that users with photosensitive epilepsy can use modern computer monitors set to a refresh rate of 75 Hz or above safely without risk of seizure. [1] Nonetheless, certain flashing images, particularly those containing regular patterns of lines, pose a risk to these viewers.
Those susceptible are strongly urged to take precautions on their own computers to protect themselves from such triggers. Some pages (such as Horse gait) display animations which play directly upon loading unless the user's Web browser settings prohibit it. Many potential editors will not think about epilepsy when adding animations to an article.
Web Content Accessibility Guidelines Section 2.3 discourages the use of text or images which flash between bright and dark values more than three times per second. Guidelines established for other media, such as the ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television, have advised caution when displaying regular striped patterns over more than 40% of the screen area or flashing striped patterns over 25% of the screen area. Wikipedia editors can improve the safety and accessibility of Wikipedia by considering these recommendations.
I welcome your comments. Mike Serfas ( talk) 02:14, 4 August 2009 (UTC)
There's an active discussion in Wikipedia talk:Featured article candidates about whether we should remove the requirement that featured articles have alt text to help visually impaired readers. In that discussion, please see the sections Alt text in images through Alt text for portraits, particularly the wording changes being proposed in Where things stand. I am interested in feedback about the claims in this discussion that alt text does not help visually impaired readers. Eubulides ( talk) 17:51, 5 August 2009 (UTC)
A recent edit added this text:
So I'm curious: what does a screen reader typically do when it's given text with unusual characters? Here are three examples: (1) "→"; (2) "^"; (3) "²".
Also, I don't agree with the proposal to replace "^" with an icon. Let's put it this way: the "^" is not an essential part of the article and doesn't need heavyweight support. Or another way: it's just as confusing for sighted readers as for the visually impaired, so there's no WP:ACCESSIBILITY argument for using an icon. Eubulides ( talk) 00:28, 22 August 2009 (UTC)
title
attributes in links. But be aware that assistive technology is in development, and improves as demand expand. So provinding title
attributes in links is not a bad idea at all. See
H33: Supplementing link text with the title attribute, techniques for WCAG 2.0.Just for informational purposes, my wife, who has a severe visual impairment, uses a screen enlargement/reader combination program called ZoomText. In its current configuration, it ignores unicode entirely when in screen-reading mode. - Dewelar ( talk) 00:21, 23 August 2009 (UTC)
Following up on the above discussion, I added two sections to the alt text guidelines. WP:ALT#Math discusses math formulas and follows Graham's suggestion in saying that simple formulas are an easy case for alt text, whereas complex ones may be better rendered as the LaTeX. As it happens, if you don't specify alt text for a math formula, it defaults to the LaTeX, so that simplifies matters. WP:ALT#Text discusses images containing prominent text, Unicode, etc. I had the most fun writing the suggestion that alt text say "Spiral staircase" rather than "꩜ ▁▂▃▄▅▆▇█"; that latter quote is valid Unicode but it doesn't even render correctly on my browser, which is the latest Firefox. Further comments here (or at WT:ALT) are welcome. Eubulides ( talk) 17:10, 31 August 2009 (UTC)
How might we improve the accessibility of pages like Common year starting on Saturday? Leap year starting on Sunday which uses {{ Year3}}, seems better, but barely so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:03, 31 August 2009 (UTC)
Mo | Tu | We | Th | Fr | Sa | Su | |
---|---|---|---|---|---|---|---|
Week 1 | 1 | 2 | |||||
Week 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
Week 3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
Week 4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
Week 5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
Week 6 | 31 |
<abbr>
elements for the day-names?
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits 14:38, 31 August 2009 (UTC)
abbr
should be an attribute of the th
element, no? That is, "<th abbr="Monday"...>Mo</th>
". Second, those "Week 1" row headers are a big distraction to the sighted reader; shouldn't they be made invisible?
Eubulides (
talk) 17:19, 31 August 2009 (UTC)
← Visually, this may be better:
Week | Mo | Tu | We | Th | Fr | Sa | Su |
---|---|---|---|---|---|---|---|
1 | 1 | 2 | |||||
2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
6 | 31 |
abbr
element is now implemented in MediaWiki!Week | Mo | Tu | We | Th | Fr | Sa | Su |
---|---|---|---|---|---|---|---|
1 | 1 | 2 | |||||
2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
3 | 10 | 11 | 12 | 13 | 14 | 15 | 16 |
4 | 17 | 18 | 19 | 20 | 21 | 22 | 23 |
5 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |
6 | 31 |
The abbr
element was implemented in the
last MediaWIki update! That's great news See
bugzilla:671, the community was asking fot that element since 2004. So I just made a new table using the abbr
element. See
H28: Providing definitions for abbreviations by using the abbr and acronym elements, Techniques for WCAG 2.0, W3C for further information.
By the way, the abbr
attribute in a td
element does the opposite of the abbr
element : it is made to display an abreviation of a long header content to the screen reader. "When table header content is repeatedly rendered by the user agent, the content of the abbr
attribute should be rendered in place of table header content." See
the ABBR attribute for TH elements, WAI, W3C for further details on how to use it. Yours,
Dodoïste (
talk) 20:43, 28 September 2009 (UTC)
<abbr>
instead of a Wikilink. That is, "{{circa|1100}}
" used to output "
c. 1100"; now it outputs "
c. 1100". This is better for sighted readers as it uses the more-common mechanism for abbreviations; I hope it's OK accessibility-wise.
Eubulides (
talk) 16:34, 29 September 2009 (UTC)
Please see and comment. Thanks, – xeno talk 14:55, 31 August 2009 (UTC)
Please clarify at [13]. Thanks, Dabomb87 ( talk) 13:32, 13 September 2009 (UTC)
Is it a problem to use images in section headers, such as Wikipedia:WikiProject Lancashire and Cumbria? Dabomb87 ( talk) 22:11, 16 September 2009 (UTC)
|link=
as per
WP:ALT #Purely decorative images. I
did that. I don't see an accessibility issue once this is done. You might want to let other projects know about |link=
, if they use this style.
Eubulides (
talk) 22:36, 16 September 2009 (UTC)