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 1 | Archive 2 | Archive 3 | → | Archive 5 |
I ran the wikipedia main page in [ Bobby] which checks web pages for accessiblity issues.
I strongly feel that Wikipedia software writers should help make pages more accesibility friendly so that 'challenged people' should not have a problem. What do you think? Nichalp
For the record, I checked our main page for w3c compliance, and it failed. see here →Raul654 19:32, Mar 29, 2004 (UTC)
Because of internal changes to Wikipedia's template code, some editors are systematically changing the way that a number of reference templates work. Junk code is being inserted into the text of the page, and then hidden using CSS. There is an alternative solution, but this method appears to be chosen because it is easier to implement, and accessibility is being ignored. This is appallingly contrary to the principal that Wikipedia should be accessible to all users. Please see the discussion at Template talk:Journal reference#Junk code, and make your opinion heard. — Michael Z. 2006-01-16 17:41 Z
EVERYONE - in order to quash this ForestFire, please follow-up discussion at MediaWiki talk:Common.css#CSS hack reduces accessibility. -- Netoholic @ 19:08, 16 January 2006 (UTC)
Note the audio versions of some articles. – Quadell ( talk) ( bounties) 20:16, 18 January 2006 (UTC)
Do Jaws or other screen readers support table summaries? The summary would be placed in an attribute of the table. As opposed to a caption, it summarizes the content of the table. Not just what it is, but what it says. — Michael Z. 2006-01-24 21:03 Z
Example:
{| summary="GNP rose 30%, but unemployment stayed level" |+ Economic indicators, 2006 |- ! [header] | [table body] |}
Netoholic, thanks for adding Pianoman87's recommendations. It's rare and helpful to have real-world advice, specific to Wikipedia. Regards. — Michael Z. 2006-01-24 21:04 Z
Maybe some existing templates should be encouraged for accesibility reasons, namely Template:lang (and Template:Polytonic) and Template:IPA. Thanks to the metadata added by those templates —XHTML/HTML attributes lang (and xml:lang) by the former, and class="IPA" by the latter— will allow screen readers to interpret foreing words and IPA symbols correctly. -- surueña 14:44, 10 March 2006 (UTC)
I think more could be done for people with visual disabilities regarding images. Caption almost never tell what the image contains. It wouldn't be that hard to create a mechanism for image descriptions, perhaps an alternate name space in commons. There could also be a place for visually impaired people to request alternate descriptions for images that they have interest in. At the very least, there could be a standard syntax for an alternate description text on the image's description page so people wouldn't have to wade through all the licensing stuff and some mention of the need for descriptions, with a link to a page with some examples of good practice, on the upload page.-- agr 19:32, 31 March 2006 (UTC)
[[Attribute:Description|descriptive text.]]
I don't think the advice about using Windows-1252 or Latin-1 characters instead of other Unicode characters is very useful because the HTML pages send by MediaWiki are encoded in UTF-8. This is not a problem about the Windows-1252 or Latin-1 encodings (i.e. not a Windows vs. Linux issue or a Latin-1 vs. other non-Western ISO-8859 encodings). These two encodings are widely used and supported, but even those articles written only with ASCII characters are sent with the "UTF-8" tag.
The first 256 characters of Unicode are identical to the whole Latin-1, however no text encoded in Latin-1 (using any of the upper half) is also a valid UTF-8 string (neither a Windows-1252 text, of course). That's because the first 128 Unicode characters are encoded using 1 byte, but for the next 128 characters 2 bytes are needed. Therefore a pure 7-bit ASCII string is a valid UTF-8, but not a Latin-1 or Windows-1252 text.
This advice will require changes in the MediaWiki software: when submiting an article the server would need to check whether it's only composed by Windows-1252 characters, and later send it to users with special HTTP headers ("charset=windows-1252" instead of "charset=UTF-8"). Of course it could be done, but IMHO it's not a good idea (and probably developers think the same). If screen readers don't support UTF-8/Unicode they should be updated because nowadays the W3 is adopting Unicode.
In summary: That guideline should be removed from the policy. Or am I missing something? Thank you -- surueña 15:24, 10 May 2006 (UTC)
I can think of a few characters where such advice could increase accessibility for screen readers or non-Unicode browsers, but it's an exceedingly thin sliver of cases between ISO Latin and the full breadth of Unicode, and difficult for the average editor to figure out which substitutions would actually be helpful. I would recommend the standard Latin-1 character set over Microsoft's proprietary Windows-1252.
Latin entities might make a bit of sense if they're read out, but on the other hand I recall from my Netscape 4.0 days that a few characters would be rendered correctly if included in the page as decimal entities, but show up as question marks if entered as Latin entities.
Code pages in Jaws hardly sound like they're worth messing around with unless you are interested in a subject where one particular language is used, since you would still have to choose a single one. A single Wikipedia article can easily have characters from several different code pages (e.g. accented Latin, IPA pronunciation, and one or more foreign-language scripts or some technical or mathematics symbols). I wonder if the developers are considering adding real Unicode capability—it sounds like even just reading out a characters' Unicode name would be far superior to the way it works now. Too bad a USD $900 screen reader (Jaws) can't have the same basic text savvy that a free text-only browser (Lynx) does. — Michael Z. 2006-05-12 21:14 Z
I wonder if there is a way to make the timelines accessible with screen readers? At the moment, when navigating through a timeline, all I get is image map links but no years. It would be nice if I could find out in what years something occurred; for an example see history of computing. Could the years be added to the image description, or would this just make the timeline look ugly? Graham talk 11:58, 13 May 2006 (UTC)
<area shape="rect" href="/info/en/?search=Moore's_law" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />
<area shape="rect" href="/info/en/?search=Gordon_E._Moore" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />
Hello Graham, how do you do? As you know, I'm currently working in the Wikipedia:Accessibility project, and there's much work to do… I would like to know what are the biggest accessibility problems of Wikipedia, for working on them first. Image descriptions? Articles' structure? Unicode texts? The opinion of a JAWS user is very valuable, thanks! Best regards -- surueña 10:13, 13 May 2006 (UTC)
Is there a way to mark a link as less important, so JAWS will skip over it in normal reading, perhaps using a rel attribute? If so, this could be built into the automatic date formatter. — Michael Z. 2006-05-14 20:37 Z
Hello, how do you do? I saw that you think that not every info or series boxes are layout tables (i.e. some of them are data tables), and that's great because I've thinking about it for some time and I believe the opposite, but because I'm not sure I would like to know more opinions.
From my POV all infoboxes I've seen are no data tables. See for example {{
Infobox Country}}
or {{
Infobox Episode}}. Sometime ago
I believed that those infoboxes were data tables, and therefore they should have row & column headers and a caption for accessibility reasons. Row headers were easy to find, but what about column headers? I can't find them in any infobox. And in series boxes I could't find even row headers. And that's because in my opinion they aren't a 2D data table with raw data like {{
Most Active Regional blocs}}
, but the cells are only used for layout purposes.
But I would like to disscus it while developing the Wikipedia:Accessibility policy (really). Am I missing something? Best regards, surueña 15:59, 10 May 2006 (UTC)
{{
EU}}
) / series box ({{
History of Spain}}
) / succession box ({{
sequence}}
). I'm very interested. Thanks --
surueña
18:38, 11 May 2006 (UTC)
As I disagree with all modifications yesterday I've reverted them. -- Omniplex 01:53, 15 May 2006 (UTC)
I don't see the point of making the table of contents left or right aligned, nor is it a problem for me. However, I do object to putting the table of contents above the intro, because it breaks the heading structure I (and probably all other users of screen readers) expect. I've made several edits to fix this at prominent articles like Isotope, poker, and most recently nobel peace prize. Is there any reason the intro should ever be below the table of contents - does it look any better visually? If not, I might add some info about this in wikipedia:section. Graham talk 10:36, 15 May 2006 (UTC)
If you browse an aticle in Lynx or other non-graphical browser, the [edit] link is always before the section heading. Maybe it would me more logical for these browser just the reverse: after the heading. I'm not sure it's really an improvement, what do you think? A nice feature is that those edit links have a title attribute like "Edit section: See also".
Another change related with the edit button has to do with the lead section: it can only be edited editing the full article, and this link in non-graphical browsers is at the bottom of the page. IMHO, the MediaWiki should also provide an [edit] button for the lead section (section 0), as done with the other sections: it will be very useful in non-graphical browsers because it would have more visibility, but also for other users because they will be able to edit only the lead section without editing the full article (very useful for extremely big pages). HTH -- surueña 20:48, 18 May 2006 (UTC)
Some accessibility issues must be fixed by changing the MediaWiki software which runs Wikipedia's back end. Please have a look at Bug 367: Markup accessibility issues (tracking), and all of the bugs listed under "Bug 367 depends on". Leave your concise comments, and vote for these bugs to encourage the developers to address them. — Michael Z. 2006-05-19 00:32 Z
Open MediaWiki bugs: please vote for these bugs
I've noticed a number of infoboxes use a technique creating single HTML rows consisting of a number of lines, separated by newlines or BR tags, where each line has a set of labels in a cell on the left and corresponding values in the adjacent cell on the same "physical" line. I'm imagining that this is a particularly difficult arrangement to understand using a screen reader since the intended organization is line-based rather than HTML cell/row based. For example, the current version of template:Infobox Country which is used for most countries (e.g. Algeria) presents population data in this way. Am I correct that using this technique makes understanding the data in these infoboxes difficult? I have a new version of the country infobox, currently used at User:MJCdetroit/Sandbox, that makes the separate lines individual HTML rows. There are lots and lots of infobox templates that do this. If it makes a signficant accessibility difference I'm willing to fix more of them. -- Rick Block ( talk) 18:07, 29 May 2006 (UTC)
I've been thinking about layiut tables, and maybe the summary attribute should be used in infoboxes to say "This is an Infobox with basic data about the country", or something like that. It is forbidden by WCAG 1.0 and 2.0, however 2.0 guidelines are in the Last Call Draft stage, so comments are welcome (only until tomorrow 2006-05-31).
I suppose the summary attribute is forbidden because this type of secondary content should be tagged using the role attribute of the next XHTML 2.0 (role="note"). However, until this better solution is available we should use another technique supported by current browsers. What do you think? PS: Do you know any browser/assistive technology implementing the new features of XHTML 2.0? -- surueña 08:02, 30 May 2006 (UTC)
After updating some articles to the accessibility policy I have some doubts regarding JAWS behavior. Some data tables are just after a section header, and therefore adding a caption will be somewhat redundant, I suppose also for users with assistive technologies. See for example 2006 FIFA World Cup#Group F. Are all those structural elements (caption, summary, and row and column headers) needed in JAWS to be read as a data table and not as a layout table? Thanks! -- surueña 07:43, 22 June 2006 (UTC)
Joe Clark, the author of Building Accessible Websites, has written a long article about the problems he finds in both versions of WCAG (specially in the upcoming 2.0) in the webzine A List Apart. Its name says it all: " To Hell with WCAG 2". He also talks about WCAG Samurai, this can be interesting... -- surueña 16:18, 22 June 2006 (UTC)
The comments here seem a little bit like they are encouraging people to use inline colour for decoration. While this is useful in some cases, from the point of view of accessibility (and therefore this guideline), it should be discouraged. To give an example, a user (for whatever reason) changes their browser to use blue text on a yellow background and they then try to read a page which has table with lots of blue section headings. Not Good. ed g2s • talk 00:36, 7 August 2006 (UTC)
I've proposed a wkipedia wide project to find and eliminate instances within infobox-style templates of the anti-accessible technique of creating multiple visual rows withn a single row by embedding matching HTML breaks in two (or more) adjacent columns in a table, please see Wikipedia talk:WikiProject Usability#Infobox accessibility issue. This problem has been recently fixed in template:infobox country and template:infobox city. My fear is that there are hundreds of other templates with references using this formatting technique. If anyone is interested in helping with such a project please let me know (here, or at Wikipedia talk:WikiProject Usability, or on my talk page, or via email). Thanks. -- Rick Block ( talk) 03:31, 20 September 2006 (UTC)
Template:cquote, which formats block quotations as a table with purple quotation marks linked to image pages, has been proposed for deletion. Please vote or comment at Wikipedia:Templates for deletion/Log/2006 December 12#Template:Cquote. — Michael Z. 2006-12-13 17:20 Z
Template:click, which uses a wikitext/HTML/CSS hack to make links unclickable in graphical browsers, but adds confusing links to other browsers, has been proposed for deletion. Poll is at Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click. — Michael Z. 2006-12-17 17:03 Z
Template:Wikisourcesmall has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. -- surueña 21:09, 27 December 2006 (UTC)
Template:Noclick has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. -- surueña 21:09, 27 December 2006 (UTC)
I'm proud to say there are promising advances with respect template {{ click}}. As you know, it is an ugly CSS hack with several accessibility, usability, browser-compatibility, and even copyright problems, and it was totally out of control (it was used even in a user signature!). As announced above, the objective of the new project Wikipedia:WikiProject Usability/Clickable images is to remove this template completely, or at least to use it only when "absolutely necessary" (I'm optimistic, I think it can be completely removed). Similar templates were successfully removed, as you know ( Template:Wikisourcesmall, Template:Noclick).
The process is pretty smooth, but some wikipedians complained about it (in fact very, very few. Only two so far). As I'm the only contributor listed in this project, they think it isn't legitime, and clickable images aren't bad if only one wikipedian doesn't like it. I know this isn't true because some of you and other wikipedians have helped me in this issue.
I would like to ask you to join to the project, so it has enough consensus. It doesn't matter if you don't have enough time to contribute, but if you list in it as a participant I would feel enough people support me, and stop the complains (but of course contributions are always welcomed, that will be great).
Of course, any objection to this project is also welcomed. I don't want to waste so much time in something seen unimportant. Please, let me know if you think I'm wrong, thanks! Best regards, -- surueña 10:07, 13 January 2007 (UTC)
I looked for an article on JAWS and Wikipedia that would list helpful hints for the new Wikipedian using JAWS but I did not find it. So I guess I am going to go build Wikipedia:Using JAWS, PLEASE (in caps) come help complete this stub. Jeepday 19:09, 24 February 2007 (UTC)
Participants here may be interested in the following Wikipedia Manual of Style debate: Wikipedia talk:Manual of Style (dates and numbers)#Appending a period. The gist is that MOSNUM currently says to leave the period off of abbreviations of units of measurement, entirely, when this is really only appropriate for some of them, such as mm, km, dB, etc., and is not appropriate for those that are abbreviations of Imperial/American units such as feet, inches, miles, etc., which have traditionally used periods, and do so with the recommendations of the vast majority of style guides. The usability issue can be illustrated with an example: "The rod is 40.6 cm (16 in) in length" (or worse yet, "has 40.6 cm (16 in) sides"; screen readers (at least some of them) are going to say "16 in sides" which will sound like "16 insides". Some of the MOSNUM regulars are strongly resistant to the idea of restoring periods here, and I suspect that only usability/accessibility concerns are going to make a dent with the entrenched view. PS: There are several other debates relating to updating this subsection of the dates and numbers section of MoS, at Wikipedia talk:Manual of Style (dates and numbers)#Overhaul "Units of measurement" section which may be of some usability interest. I fear that the main debate I'm mentioning here is rarely raised because it is shouted down with "This is old news! We don't want to talk about it again!" attitudes (a quick review of that talk page shows several blantant examples of this ignoring of WP:CCC already); its going to take more than just me to get this fixed, I believe. PS: even from a sighted-user usability vs. accessibility issue, the current MoS-recommended practice is terrible, since English speakers parse the string "in" as a preposition not as an abbreviation for "inch(es)". — SMcCandlish [ talk] [ contrib ツ 21:11, 16 March 2007 (UTC)
I would like to suggest that Wikipedia consider ending the practice of using accesskey attributes. Many commentators have suggested that the use of accesskey attributes is beset with problems and actually causes accessibility problems. In my own case, Wikipedia's use of accesskey 'F' prevents me from using the shortcut ALT-F in IE7 to pull down the 'File' menu. Although that problem is arguably caused by a design defect in that particular browser, amongst others, and it has been suggested that the accesskey feature of HTML is inherently problematic as it forces policy onto user agents and is always at risk of denying keyboard users access to certain features of their software, even in the face of attempts by web designers to second-guess UAs and choose key assignments which will cause the fewest conflicts.
On the other hand, since the basic aim behind accesskeys was a worthwhile one even though the HTML accesskey mechanism was poorly designed and over-specified, I would suggest that Wikipedia consider continuing to offer equivalent facilities as a user-selectable option, but just not as the default. Wikipedia already documents various javascript-powered user-customisable usability enhancement mechanisms.
I would also suggest evaluating the use of other navigation-aid techniques, including meta elements such as link rel="", particularly link rel="bookmark".
References:
Article at Mezzoblue where I do not use accesskeys - Mezzoblue. That post references a number of articles written at wats.ca including wats.ca article - Accesskeys - is it worth it?.
Problems with browsers: Problems with Firefox 2.0.
Canadian government now deprecates the use of accesskeys, having previously required their use: Canadian Government now deprecates use of accesskeys. —The preceding unsigned comment was added by CecilWard ( talk • contribs) 20:25, 22 March 2007 (UTC).
The current Picture of the day, Image:Translational motion.gif is extremely distracting; it may well cause problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guidelines. I've proposed that it be replaced ASAP, and that we have an agreement to only use still images for PotD in future? Thank you. Andy Mabbett 23:22, 14 May 2007 (UTC)
There is a revert war on Template:Access icon between a version that uses a free replacement and a version that requires the reader to download one of the few fonts that contains the ISA. See also Wikipedia:Village pump (policy)/Archive BC#Is it appropriate to make people download a font to see an "unfree" unicode codepoint? -- NE2 12:05, 23 May 2007 (UTC)
If anyone watching this page knows the answer for sure, please comment on the thread at Wikipedia talk:Manual of Style#Curly quotation marks. Thanks. -- Rick Block ( talk) 02:33, 21 June 2007 (UTC)
It's always been my contention that images that serve no purpose but decoration, and which have no informative value, should not have any "alt=" text, so that they simply do not appear at all for blind users. Leaving a caption out of the [[Image:whatever.jpg|thumb|right]] should have this effect in wikicode. Is there any problem with this that I'm unaware of? Like, does an "alt=" or here a "|caption" have to be present, but simply consist of blank content, like a , or something? — SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:20, 7 August 2007 (UTC)
(copied together from talk pages of Graham87 and Lalue.)
A german user creates a JavaScript-Hack for my Monobook-JS, which put the Editlink behind the heading, so that Jaws-users (and other SR) now simply can navigate with "h" or "Shift+h" from heading to heading and always hear the section-title first. This gives me a very fast navigation and I don't need the content-menue no more.
surueña described this problem with section-editlinks and headings
here on this page. You can also use this JS, wehen you go
here, type in your username and push the "implement-button".
Here you will find the code for that very nice function. Some german admins want to implement this functionality into the MediaWiki-software, so that after this all SR-users simply can jump from heading to heading and hear the section-title first before the editlink, without needing this special JavaScript-hack. What do you think about this? regards from Kassel in Germany. --
Lalue
08:00, 10 August 2007 (UTC)
Graham 87 13:55, 10 August 2007 (UTC)
I work on such a help page at de.WP but it should been translated into other languages later, depending on the local specials in other Wikipedias. I'll hope, we both (and others?) could find out, whats all necessary for this kind of a help page ...
What version of Jaws are you using now? Which special non standard preferences do you use for Jaws? Have you experience with other screenreader-software like Window Eyes or NVDA? What browsers do you use? I use Jaws 7.1 almost with standard preferences and IE6 with classical support in the Jaws-HTML-options. I don't have a Braillebar and only use the speech synthesizer Eloquence, my best friend. ;-) --
Lalue
08:56, 11 August 2007 (UTC)
Please have a look at bug 11555. I proposed to exchange the section title and the edit link. -- Revolus 00:53, 4 October 2007 (UTC)
Why does the example have {{ featured article}} (I presume it means that and not {{ featured}}, which goes on talk pages) when Template:Featured article says that the template should be put at the bottom of the article? 17Drew 09:18, 5 September 2007 (UTC)
I am a Jaws user and frequent user and occasional contributer to Wikipedia. One element of the site I find difficult to use is the diffs. When major changes are made, its really no problem, however, unless I am mistaken, Wikipedia uses colors to indicate the exact portions of lines that have changed. What is needed is a preference which will enable screen reader users to hear these color changes. For example, deleted portions (which I believe are marked in red) could be surrounded by (-test to be deleted-) or some other similar human readable markup. Likewise for the other color indicators used. cannona 23:03, 11 September 2007 (UTC)
I've just created a subpage of my user space at User:OwenBlacker/Usability. User:Everyking and I have a disagreement over matters of accessibility and usability that I've just listed on WP:RFC/STYLE; please come and add your views. — OwenBlacker 20:03, 26 September 2007 (UTC)
Can somebody suggest a better way for dealing with List of Washington Metro stations on its talk page? Thank you. -- NE2 14:23, 6 October 2007 (UTC)
I use templates to render data tables (like the one bellow). I've tested it with a voice browser (SpeakIt 0.2.0.2 for Firefox) and I could find any problem (even the hidden text is read). So, why the guideline suggest to create data tables as explained here? Is the guideline outdated? -- ClaudioMB 00:28, 8 October 2007 (UTC)
Game |
Date |
Tournament |
Round |
Ground |
Opponent |
Score1 |
Report |
---|---|---|---|---|---|---|---|
1 | 19 Sep 2007 | UEFA Champions League | Group Stage | A | Sporting CP | 1 – 0 |
Last updated: 20 Sep 2007
Source:
UEFA Champions League 2007-08 and
FA Cup 2007-08
1Manchester United goals come first.
National flags for Ground and Opponent columns are only shown when different from that of Manchester United.
M = Match; Ground: H = Home, A = Away, N = Neutral, HR = Home replacement, AR = Away replacement.
There is a discussion about formatting at Talk:Pulp Fiction (film)#RfC: Ellipses which is relevant to this page. Can some sighted folks who know a lot about Wikipedia formatting pitch in? Graham 87 13:04, 13 October 2007 (UTC)
If this is to remain part of the MOS, it needs to be copy-edited and reviewed for clarity and structure. There are numerous breaches of MOS. Why is it flagged as a part of MOS here, but does not appear on the style template? Tony (talk) 07:51, 22 October 2007 (UTC)
I've added the following to the Colors section
I think that this is quite self-evident but should be mentioned somewhere as part of the MOS. There have been numerous templates that see red backgrounds with blue links over the top of them (I'm currently arguing at Template talk:Scuderia Ferrari about that one) and, even worse, red links on blue ( Template:University of Dayton, for example). violet/riga (t) 10:39, 22 October 2007 (UTC)
See Talk:Disability #My irony meter has just exploded for my semi-rant on struck-through text. It's common on Wikipedia discussion pages - I don't particularly mind that because there is no convenient alternative and discussion pages aren't as widely read as articles. But on articles, it shouldn't be there. An obvious exception is the article strikethrough. Graham 87 02:22, 25 October 2007 (UTC)
I'm curious; does Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text apply to hide/show buttons like used in infobox templates and templates displayed at the bottom of articles? (f.e at the bottom of Heavy metal music and the Tom Cruise infobox). Because this hide/show functionality is just a cascading style sheet trick I always thought content hidden this way is still picked up by screen readers etc.. (and when copy-pasting hidden text the hidden text is put on the "clipboard"). In other words, is this hide/show functionality an accessibility issue? Cheers Kameejl ( Talk) 10:33, 29 October 2007 (UTC)
There has been some discussion on Talk:Blink element about whether there should be a working example (as opposed to just showing the source code for an example). I've argued that if there needs to be an example of what blinking text looks like then it should be done with an image rather than the blink element so as to ensure maximum support (similar to how the examples in the SVG article are actually all PNG files generated from the original uploaded SVG). However, in an article with several paragraphs about the accessibility concerns arising from having any blinking content, it would be rather ironic to include such an image. As the issues of blinking text doesn't seem to be covered in any Wikipedia guidelines, I thought I'd ask here for advice. — Safalra ( talk) 14:04, 17 November 2007 (UTC)
I've added two suggestions from the WP:MOS about image placement, and sizing. Forcing sizing (which over-rides user's set preferences) is not advised without a good reason, because for readers who use a large font, and low resolution, it can cause display issues. Additionally, placing images underneath second level headers (===) causes display issues as well. I added those two things, and placed a link to the Images section of the manual of style. (I've verified both issues with both Firefox, and IE7, using a low resolution and oversized font, and confirm there are problems with forcing sizing for those with vision problems). Hope that's helpful! Ariel ♥ Gold 10:26, 18 November 2007 (UTC)
I have marked the Wikiproject Directory as having an accessibility problem because the tables use color as the only means of conveying whether or not a project is active. To join the discussion, see Wikipedia talk:WikiProject Council/Directory#Accessibility Problem. Thanks, L'Aquatique talk 21:26, 24 November 2007 (UTC)
The Random Acts of Kindness Barnstar | ||
To Kirill for going out of your way to fix the accessibility problem at Wikipedia:WikiProject Council/Directory. Your efforts have helped to make Wikipedia more accessible for all. Many thanks! l'Aquatique talk, Jeepday ( talk) |
What we call tooltips is in fact the standard title
attribute of an element. Is it actually known that a physical action is required to show these in all browsers? Or could some user-agents e.g. speak them along with the rest of the text. Use of e.g. <abbr>
which uses the title text is specifically recommended by many other authorities, explicitly for accessibility purposes. —
Random832
18:16, 3 December 2007 (UTC)
But what is the status of such tooltips. Screenreaders may not read them out loud, but then, if there is a link to a more explanatory document closeby, it should be fine. In the case of the template R-phrase, these links are almost exclusively used next to a wikilink (like: " R-phrases: {{R1}},{{R2}}", see e.g. Methanol, in the box on the right hand of the page, hazards section). For the majority of people the tooltips are an easy way of getting more information, though for people who have access to the tooltips, as well as those that use a screen-reader, the wikilink to what R-phrases are is next to it. In the post by Graham87 is a link to JAWS. I don't know what JAWS is, so I have to actually click the link, so that is not different from the situation as it is for people using a screen reader. Tooltips just provide a bit more on-hands information, though they should/must be used on elements where an explanatory wikilink is nearby. -- Dirk Beetstra T C 18:41, 6 December 2007 (UTC)
Expanding on this, making things more accessible would be that all wikilinks in a document would support the element of a one-liner tooltip which quickly gives more information on what lies behind it (e.g. first sentence of the document linked to), not in discouraging or forbidding the use of tooltips altogether. -- Dirk Beetstra T C 18:50, 6 December 2007 (UTC)
title
atrribute. As far as I know, in most browsers the only way to access this is by mouse hovering, but Random is right to ask that we find out exactly how screen readers do deal with them. In contrast, to follow a link you do not have to click on it. In most browsers, you can use the keyboard to tab through the links, without using the mouse (which requires much better motor control) at all. We can also assume that screen readers and so on have appropriate methods for following links, as following links is/has been a more fundamental aspect of web browsing than viewing title
attributes for a long time.title
attribute was used explicity to produce tooltips because "it would be nice to have the textual descriptions of these as well" but "I suppose that would take too much space". If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal. If it is a solution to a real problem concerning how to fit in necessary information, then there is something wrong, as the problem is still present for some users, but the partial solution means few people are aware of it. (In this particular case, the use of the templates in the context of a wikilink is relevant to this distinction, but I am not trying to make an argument for or against these templates, rather trying to use them as an example to explain the issue.)<abbr>
, as this would allow the use of tooltip while at the same time using the recommended HTML for abbreviations, which should be utilised by more and more accessbility software.
JPD (
talk)
12:17, 7 December 2007 (UTC)I think indeed that it should be in such a way that "If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal." In the R/S-phrase case in a way it is a problem there, the full sentence does not fit in the box .. but then, if you take out a catalogue where they sell chemicals, they only show 'R 1,5,7,9' as well and you have to browse to the index to find what is what. But since Wikipedia is not a paper encyclopedia, we can use features which are not possible on paper, as long as we make sure that anyone can access the information. And I believe that is the case in the R/S-phrase case. Maybe in the guideline here it should say, that tooltips/hover-texts are discouraged, but if they provide easier, hands-on information that they can be used when they do also provide a link (closeby) to more information so everyone can get to the information.
The rest would be an extended function of the mediawiki software, which would be a nice gadget. We don't have that, so that part of the question is more for Village pump, or bugzilla. -- Dirk Beetstra T C 12:44, 7 December 2007 (UTC)
I've used sometimes and contributed to/created the templates {{ abbr}} and {{ abbrlink}} (but they are somewhat experimental) as a way to fix the lack of the HTML <abbr> tag — a tag which can improve accessibility. [7] My idea was to create these templates so people start using it, and meanwhile submit a bug report. [8] Finally, when MediaWiki supports this HTML tag my plan was to modify these template using the <abbr> tag instead of a tooltip. Hope this helps — surueña 22:00, 9 December 2007 (UTC)
Over on the various Amazing Race season pages (such as The Amazing Race 12), we have a series of icons that reflect tasks that are done on the show. The images (from Commons, and placed through templates) have alt text to describe the icon, and just recently we are adding a key to what the images are for those completely unfamiliar with the show (as see at the start of this section. One editor suggested that via accessibility, this may not be strictly appropriate since we're using images to convey information. I would like to check if there's any problems with this approach and if we need to consider something else. -- MASEM 00:07, 8 December 2007 (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 1 | Archive 2 | Archive 3 | → | Archive 5 |
I ran the wikipedia main page in [ Bobby] which checks web pages for accessiblity issues.
I strongly feel that Wikipedia software writers should help make pages more accesibility friendly so that 'challenged people' should not have a problem. What do you think? Nichalp
For the record, I checked our main page for w3c compliance, and it failed. see here →Raul654 19:32, Mar 29, 2004 (UTC)
Because of internal changes to Wikipedia's template code, some editors are systematically changing the way that a number of reference templates work. Junk code is being inserted into the text of the page, and then hidden using CSS. There is an alternative solution, but this method appears to be chosen because it is easier to implement, and accessibility is being ignored. This is appallingly contrary to the principal that Wikipedia should be accessible to all users. Please see the discussion at Template talk:Journal reference#Junk code, and make your opinion heard. — Michael Z. 2006-01-16 17:41 Z
EVERYONE - in order to quash this ForestFire, please follow-up discussion at MediaWiki talk:Common.css#CSS hack reduces accessibility. -- Netoholic @ 19:08, 16 January 2006 (UTC)
Note the audio versions of some articles. – Quadell ( talk) ( bounties) 20:16, 18 January 2006 (UTC)
Do Jaws or other screen readers support table summaries? The summary would be placed in an attribute of the table. As opposed to a caption, it summarizes the content of the table. Not just what it is, but what it says. — Michael Z. 2006-01-24 21:03 Z
Example:
{| summary="GNP rose 30%, but unemployment stayed level" |+ Economic indicators, 2006 |- ! [header] | [table body] |}
Netoholic, thanks for adding Pianoman87's recommendations. It's rare and helpful to have real-world advice, specific to Wikipedia. Regards. — Michael Z. 2006-01-24 21:04 Z
Maybe some existing templates should be encouraged for accesibility reasons, namely Template:lang (and Template:Polytonic) and Template:IPA. Thanks to the metadata added by those templates —XHTML/HTML attributes lang (and xml:lang) by the former, and class="IPA" by the latter— will allow screen readers to interpret foreing words and IPA symbols correctly. -- surueña 14:44, 10 March 2006 (UTC)
I think more could be done for people with visual disabilities regarding images. Caption almost never tell what the image contains. It wouldn't be that hard to create a mechanism for image descriptions, perhaps an alternate name space in commons. There could also be a place for visually impaired people to request alternate descriptions for images that they have interest in. At the very least, there could be a standard syntax for an alternate description text on the image's description page so people wouldn't have to wade through all the licensing stuff and some mention of the need for descriptions, with a link to a page with some examples of good practice, on the upload page.-- agr 19:32, 31 March 2006 (UTC)
[[Attribute:Description|descriptive text.]]
I don't think the advice about using Windows-1252 or Latin-1 characters instead of other Unicode characters is very useful because the HTML pages send by MediaWiki are encoded in UTF-8. This is not a problem about the Windows-1252 or Latin-1 encodings (i.e. not a Windows vs. Linux issue or a Latin-1 vs. other non-Western ISO-8859 encodings). These two encodings are widely used and supported, but even those articles written only with ASCII characters are sent with the "UTF-8" tag.
The first 256 characters of Unicode are identical to the whole Latin-1, however no text encoded in Latin-1 (using any of the upper half) is also a valid UTF-8 string (neither a Windows-1252 text, of course). That's because the first 128 Unicode characters are encoded using 1 byte, but for the next 128 characters 2 bytes are needed. Therefore a pure 7-bit ASCII string is a valid UTF-8, but not a Latin-1 or Windows-1252 text.
This advice will require changes in the MediaWiki software: when submiting an article the server would need to check whether it's only composed by Windows-1252 characters, and later send it to users with special HTTP headers ("charset=windows-1252" instead of "charset=UTF-8"). Of course it could be done, but IMHO it's not a good idea (and probably developers think the same). If screen readers don't support UTF-8/Unicode they should be updated because nowadays the W3 is adopting Unicode.
In summary: That guideline should be removed from the policy. Or am I missing something? Thank you -- surueña 15:24, 10 May 2006 (UTC)
I can think of a few characters where such advice could increase accessibility for screen readers or non-Unicode browsers, but it's an exceedingly thin sliver of cases between ISO Latin and the full breadth of Unicode, and difficult for the average editor to figure out which substitutions would actually be helpful. I would recommend the standard Latin-1 character set over Microsoft's proprietary Windows-1252.
Latin entities might make a bit of sense if they're read out, but on the other hand I recall from my Netscape 4.0 days that a few characters would be rendered correctly if included in the page as decimal entities, but show up as question marks if entered as Latin entities.
Code pages in Jaws hardly sound like they're worth messing around with unless you are interested in a subject where one particular language is used, since you would still have to choose a single one. A single Wikipedia article can easily have characters from several different code pages (e.g. accented Latin, IPA pronunciation, and one or more foreign-language scripts or some technical or mathematics symbols). I wonder if the developers are considering adding real Unicode capability—it sounds like even just reading out a characters' Unicode name would be far superior to the way it works now. Too bad a USD $900 screen reader (Jaws) can't have the same basic text savvy that a free text-only browser (Lynx) does. — Michael Z. 2006-05-12 21:14 Z
I wonder if there is a way to make the timelines accessible with screen readers? At the moment, when navigating through a timeline, all I get is image map links but no years. It would be nice if I could find out in what years something occurred; for an example see history of computing. Could the years be added to the image description, or would this just make the timeline look ugly? Graham talk 11:58, 13 May 2006 (UTC)
<area shape="rect" href="/info/en/?search=Moore's_law" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />
<area shape="rect" href="/info/en/?search=Gordon_E._Moore" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />
Hello Graham, how do you do? As you know, I'm currently working in the Wikipedia:Accessibility project, and there's much work to do… I would like to know what are the biggest accessibility problems of Wikipedia, for working on them first. Image descriptions? Articles' structure? Unicode texts? The opinion of a JAWS user is very valuable, thanks! Best regards -- surueña 10:13, 13 May 2006 (UTC)
Is there a way to mark a link as less important, so JAWS will skip over it in normal reading, perhaps using a rel attribute? If so, this could be built into the automatic date formatter. — Michael Z. 2006-05-14 20:37 Z
Hello, how do you do? I saw that you think that not every info or series boxes are layout tables (i.e. some of them are data tables), and that's great because I've thinking about it for some time and I believe the opposite, but because I'm not sure I would like to know more opinions.
From my POV all infoboxes I've seen are no data tables. See for example {{
Infobox Country}}
or {{
Infobox Episode}}. Sometime ago
I believed that those infoboxes were data tables, and therefore they should have row & column headers and a caption for accessibility reasons. Row headers were easy to find, but what about column headers? I can't find them in any infobox. And in series boxes I could't find even row headers. And that's because in my opinion they aren't a 2D data table with raw data like {{
Most Active Regional blocs}}
, but the cells are only used for layout purposes.
But I would like to disscus it while developing the Wikipedia:Accessibility policy (really). Am I missing something? Best regards, surueña 15:59, 10 May 2006 (UTC)
{{
EU}}
) / series box ({{
History of Spain}}
) / succession box ({{
sequence}}
). I'm very interested. Thanks --
surueña
18:38, 11 May 2006 (UTC)
As I disagree with all modifications yesterday I've reverted them. -- Omniplex 01:53, 15 May 2006 (UTC)
I don't see the point of making the table of contents left or right aligned, nor is it a problem for me. However, I do object to putting the table of contents above the intro, because it breaks the heading structure I (and probably all other users of screen readers) expect. I've made several edits to fix this at prominent articles like Isotope, poker, and most recently nobel peace prize. Is there any reason the intro should ever be below the table of contents - does it look any better visually? If not, I might add some info about this in wikipedia:section. Graham talk 10:36, 15 May 2006 (UTC)
If you browse an aticle in Lynx or other non-graphical browser, the [edit] link is always before the section heading. Maybe it would me more logical for these browser just the reverse: after the heading. I'm not sure it's really an improvement, what do you think? A nice feature is that those edit links have a title attribute like "Edit section: See also".
Another change related with the edit button has to do with the lead section: it can only be edited editing the full article, and this link in non-graphical browsers is at the bottom of the page. IMHO, the MediaWiki should also provide an [edit] button for the lead section (section 0), as done with the other sections: it will be very useful in non-graphical browsers because it would have more visibility, but also for other users because they will be able to edit only the lead section without editing the full article (very useful for extremely big pages). HTH -- surueña 20:48, 18 May 2006 (UTC)
Some accessibility issues must be fixed by changing the MediaWiki software which runs Wikipedia's back end. Please have a look at Bug 367: Markup accessibility issues (tracking), and all of the bugs listed under "Bug 367 depends on". Leave your concise comments, and vote for these bugs to encourage the developers to address them. — Michael Z. 2006-05-19 00:32 Z
Open MediaWiki bugs: please vote for these bugs
I've noticed a number of infoboxes use a technique creating single HTML rows consisting of a number of lines, separated by newlines or BR tags, where each line has a set of labels in a cell on the left and corresponding values in the adjacent cell on the same "physical" line. I'm imagining that this is a particularly difficult arrangement to understand using a screen reader since the intended organization is line-based rather than HTML cell/row based. For example, the current version of template:Infobox Country which is used for most countries (e.g. Algeria) presents population data in this way. Am I correct that using this technique makes understanding the data in these infoboxes difficult? I have a new version of the country infobox, currently used at User:MJCdetroit/Sandbox, that makes the separate lines individual HTML rows. There are lots and lots of infobox templates that do this. If it makes a signficant accessibility difference I'm willing to fix more of them. -- Rick Block ( talk) 18:07, 29 May 2006 (UTC)
I've been thinking about layiut tables, and maybe the summary attribute should be used in infoboxes to say "This is an Infobox with basic data about the country", or something like that. It is forbidden by WCAG 1.0 and 2.0, however 2.0 guidelines are in the Last Call Draft stage, so comments are welcome (only until tomorrow 2006-05-31).
I suppose the summary attribute is forbidden because this type of secondary content should be tagged using the role attribute of the next XHTML 2.0 (role="note"). However, until this better solution is available we should use another technique supported by current browsers. What do you think? PS: Do you know any browser/assistive technology implementing the new features of XHTML 2.0? -- surueña 08:02, 30 May 2006 (UTC)
After updating some articles to the accessibility policy I have some doubts regarding JAWS behavior. Some data tables are just after a section header, and therefore adding a caption will be somewhat redundant, I suppose also for users with assistive technologies. See for example 2006 FIFA World Cup#Group F. Are all those structural elements (caption, summary, and row and column headers) needed in JAWS to be read as a data table and not as a layout table? Thanks! -- surueña 07:43, 22 June 2006 (UTC)
Joe Clark, the author of Building Accessible Websites, has written a long article about the problems he finds in both versions of WCAG (specially in the upcoming 2.0) in the webzine A List Apart. Its name says it all: " To Hell with WCAG 2". He also talks about WCAG Samurai, this can be interesting... -- surueña 16:18, 22 June 2006 (UTC)
The comments here seem a little bit like they are encouraging people to use inline colour for decoration. While this is useful in some cases, from the point of view of accessibility (and therefore this guideline), it should be discouraged. To give an example, a user (for whatever reason) changes their browser to use blue text on a yellow background and they then try to read a page which has table with lots of blue section headings. Not Good. ed g2s • talk 00:36, 7 August 2006 (UTC)
I've proposed a wkipedia wide project to find and eliminate instances within infobox-style templates of the anti-accessible technique of creating multiple visual rows withn a single row by embedding matching HTML breaks in two (or more) adjacent columns in a table, please see Wikipedia talk:WikiProject Usability#Infobox accessibility issue. This problem has been recently fixed in template:infobox country and template:infobox city. My fear is that there are hundreds of other templates with references using this formatting technique. If anyone is interested in helping with such a project please let me know (here, or at Wikipedia talk:WikiProject Usability, or on my talk page, or via email). Thanks. -- Rick Block ( talk) 03:31, 20 September 2006 (UTC)
Template:cquote, which formats block quotations as a table with purple quotation marks linked to image pages, has been proposed for deletion. Please vote or comment at Wikipedia:Templates for deletion/Log/2006 December 12#Template:Cquote. — Michael Z. 2006-12-13 17:20 Z
Template:click, which uses a wikitext/HTML/CSS hack to make links unclickable in graphical browsers, but adds confusing links to other browsers, has been proposed for deletion. Poll is at Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click. — Michael Z. 2006-12-17 17:03 Z
Template:Wikisourcesmall has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. -- surueña 21:09, 27 December 2006 (UTC)
Template:Noclick has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. -- surueña 21:09, 27 December 2006 (UTC)
I'm proud to say there are promising advances with respect template {{ click}}. As you know, it is an ugly CSS hack with several accessibility, usability, browser-compatibility, and even copyright problems, and it was totally out of control (it was used even in a user signature!). As announced above, the objective of the new project Wikipedia:WikiProject Usability/Clickable images is to remove this template completely, or at least to use it only when "absolutely necessary" (I'm optimistic, I think it can be completely removed). Similar templates were successfully removed, as you know ( Template:Wikisourcesmall, Template:Noclick).
The process is pretty smooth, but some wikipedians complained about it (in fact very, very few. Only two so far). As I'm the only contributor listed in this project, they think it isn't legitime, and clickable images aren't bad if only one wikipedian doesn't like it. I know this isn't true because some of you and other wikipedians have helped me in this issue.
I would like to ask you to join to the project, so it has enough consensus. It doesn't matter if you don't have enough time to contribute, but if you list in it as a participant I would feel enough people support me, and stop the complains (but of course contributions are always welcomed, that will be great).
Of course, any objection to this project is also welcomed. I don't want to waste so much time in something seen unimportant. Please, let me know if you think I'm wrong, thanks! Best regards, -- surueña 10:07, 13 January 2007 (UTC)
I looked for an article on JAWS and Wikipedia that would list helpful hints for the new Wikipedian using JAWS but I did not find it. So I guess I am going to go build Wikipedia:Using JAWS, PLEASE (in caps) come help complete this stub. Jeepday 19:09, 24 February 2007 (UTC)
Participants here may be interested in the following Wikipedia Manual of Style debate: Wikipedia talk:Manual of Style (dates and numbers)#Appending a period. The gist is that MOSNUM currently says to leave the period off of abbreviations of units of measurement, entirely, when this is really only appropriate for some of them, such as mm, km, dB, etc., and is not appropriate for those that are abbreviations of Imperial/American units such as feet, inches, miles, etc., which have traditionally used periods, and do so with the recommendations of the vast majority of style guides. The usability issue can be illustrated with an example: "The rod is 40.6 cm (16 in) in length" (or worse yet, "has 40.6 cm (16 in) sides"; screen readers (at least some of them) are going to say "16 in sides" which will sound like "16 insides". Some of the MOSNUM regulars are strongly resistant to the idea of restoring periods here, and I suspect that only usability/accessibility concerns are going to make a dent with the entrenched view. PS: There are several other debates relating to updating this subsection of the dates and numbers section of MoS, at Wikipedia talk:Manual of Style (dates and numbers)#Overhaul "Units of measurement" section which may be of some usability interest. I fear that the main debate I'm mentioning here is rarely raised because it is shouted down with "This is old news! We don't want to talk about it again!" attitudes (a quick review of that talk page shows several blantant examples of this ignoring of WP:CCC already); its going to take more than just me to get this fixed, I believe. PS: even from a sighted-user usability vs. accessibility issue, the current MoS-recommended practice is terrible, since English speakers parse the string "in" as a preposition not as an abbreviation for "inch(es)". — SMcCandlish [ talk] [ contrib ツ 21:11, 16 March 2007 (UTC)
I would like to suggest that Wikipedia consider ending the practice of using accesskey attributes. Many commentators have suggested that the use of accesskey attributes is beset with problems and actually causes accessibility problems. In my own case, Wikipedia's use of accesskey 'F' prevents me from using the shortcut ALT-F in IE7 to pull down the 'File' menu. Although that problem is arguably caused by a design defect in that particular browser, amongst others, and it has been suggested that the accesskey feature of HTML is inherently problematic as it forces policy onto user agents and is always at risk of denying keyboard users access to certain features of their software, even in the face of attempts by web designers to second-guess UAs and choose key assignments which will cause the fewest conflicts.
On the other hand, since the basic aim behind accesskeys was a worthwhile one even though the HTML accesskey mechanism was poorly designed and over-specified, I would suggest that Wikipedia consider continuing to offer equivalent facilities as a user-selectable option, but just not as the default. Wikipedia already documents various javascript-powered user-customisable usability enhancement mechanisms.
I would also suggest evaluating the use of other navigation-aid techniques, including meta elements such as link rel="", particularly link rel="bookmark".
References:
Article at Mezzoblue where I do not use accesskeys - Mezzoblue. That post references a number of articles written at wats.ca including wats.ca article - Accesskeys - is it worth it?.
Problems with browsers: Problems with Firefox 2.0.
Canadian government now deprecates the use of accesskeys, having previously required their use: Canadian Government now deprecates use of accesskeys. —The preceding unsigned comment was added by CecilWard ( talk • contribs) 20:25, 22 March 2007 (UTC).
The current Picture of the day, Image:Translational motion.gif is extremely distracting; it may well cause problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guidelines. I've proposed that it be replaced ASAP, and that we have an agreement to only use still images for PotD in future? Thank you. Andy Mabbett 23:22, 14 May 2007 (UTC)
There is a revert war on Template:Access icon between a version that uses a free replacement and a version that requires the reader to download one of the few fonts that contains the ISA. See also Wikipedia:Village pump (policy)/Archive BC#Is it appropriate to make people download a font to see an "unfree" unicode codepoint? -- NE2 12:05, 23 May 2007 (UTC)
If anyone watching this page knows the answer for sure, please comment on the thread at Wikipedia talk:Manual of Style#Curly quotation marks. Thanks. -- Rick Block ( talk) 02:33, 21 June 2007 (UTC)
It's always been my contention that images that serve no purpose but decoration, and which have no informative value, should not have any "alt=" text, so that they simply do not appear at all for blind users. Leaving a caption out of the [[Image:whatever.jpg|thumb|right]] should have this effect in wikicode. Is there any problem with this that I'm unaware of? Like, does an "alt=" or here a "|caption" have to be present, but simply consist of blank content, like a , or something? — SMcCandlish [ talk] [ cont] ‹(-¿-)› 18:20, 7 August 2007 (UTC)
(copied together from talk pages of Graham87 and Lalue.)
A german user creates a JavaScript-Hack for my Monobook-JS, which put the Editlink behind the heading, so that Jaws-users (and other SR) now simply can navigate with "h" or "Shift+h" from heading to heading and always hear the section-title first. This gives me a very fast navigation and I don't need the content-menue no more.
surueña described this problem with section-editlinks and headings
here on this page. You can also use this JS, wehen you go
here, type in your username and push the "implement-button".
Here you will find the code for that very nice function. Some german admins want to implement this functionality into the MediaWiki-software, so that after this all SR-users simply can jump from heading to heading and hear the section-title first before the editlink, without needing this special JavaScript-hack. What do you think about this? regards from Kassel in Germany. --
Lalue
08:00, 10 August 2007 (UTC)
Graham 87 13:55, 10 August 2007 (UTC)
I work on such a help page at de.WP but it should been translated into other languages later, depending on the local specials in other Wikipedias. I'll hope, we both (and others?) could find out, whats all necessary for this kind of a help page ...
What version of Jaws are you using now? Which special non standard preferences do you use for Jaws? Have you experience with other screenreader-software like Window Eyes or NVDA? What browsers do you use? I use Jaws 7.1 almost with standard preferences and IE6 with classical support in the Jaws-HTML-options. I don't have a Braillebar and only use the speech synthesizer Eloquence, my best friend. ;-) --
Lalue
08:56, 11 August 2007 (UTC)
Please have a look at bug 11555. I proposed to exchange the section title and the edit link. -- Revolus 00:53, 4 October 2007 (UTC)
Why does the example have {{ featured article}} (I presume it means that and not {{ featured}}, which goes on talk pages) when Template:Featured article says that the template should be put at the bottom of the article? 17Drew 09:18, 5 September 2007 (UTC)
I am a Jaws user and frequent user and occasional contributer to Wikipedia. One element of the site I find difficult to use is the diffs. When major changes are made, its really no problem, however, unless I am mistaken, Wikipedia uses colors to indicate the exact portions of lines that have changed. What is needed is a preference which will enable screen reader users to hear these color changes. For example, deleted portions (which I believe are marked in red) could be surrounded by (-test to be deleted-) or some other similar human readable markup. Likewise for the other color indicators used. cannona 23:03, 11 September 2007 (UTC)
I've just created a subpage of my user space at User:OwenBlacker/Usability. User:Everyking and I have a disagreement over matters of accessibility and usability that I've just listed on WP:RFC/STYLE; please come and add your views. — OwenBlacker 20:03, 26 September 2007 (UTC)
Can somebody suggest a better way for dealing with List of Washington Metro stations on its talk page? Thank you. -- NE2 14:23, 6 October 2007 (UTC)
I use templates to render data tables (like the one bellow). I've tested it with a voice browser (SpeakIt 0.2.0.2 for Firefox) and I could find any problem (even the hidden text is read). So, why the guideline suggest to create data tables as explained here? Is the guideline outdated? -- ClaudioMB 00:28, 8 October 2007 (UTC)
Game |
Date |
Tournament |
Round |
Ground |
Opponent |
Score1 |
Report |
---|---|---|---|---|---|---|---|
1 | 19 Sep 2007 | UEFA Champions League | Group Stage | A | Sporting CP | 1 – 0 |
Last updated: 20 Sep 2007
Source:
UEFA Champions League 2007-08 and
FA Cup 2007-08
1Manchester United goals come first.
National flags for Ground and Opponent columns are only shown when different from that of Manchester United.
M = Match; Ground: H = Home, A = Away, N = Neutral, HR = Home replacement, AR = Away replacement.
There is a discussion about formatting at Talk:Pulp Fiction (film)#RfC: Ellipses which is relevant to this page. Can some sighted folks who know a lot about Wikipedia formatting pitch in? Graham 87 13:04, 13 October 2007 (UTC)
If this is to remain part of the MOS, it needs to be copy-edited and reviewed for clarity and structure. There are numerous breaches of MOS. Why is it flagged as a part of MOS here, but does not appear on the style template? Tony (talk) 07:51, 22 October 2007 (UTC)
I've added the following to the Colors section
I think that this is quite self-evident but should be mentioned somewhere as part of the MOS. There have been numerous templates that see red backgrounds with blue links over the top of them (I'm currently arguing at Template talk:Scuderia Ferrari about that one) and, even worse, red links on blue ( Template:University of Dayton, for example). violet/riga (t) 10:39, 22 October 2007 (UTC)
See Talk:Disability #My irony meter has just exploded for my semi-rant on struck-through text. It's common on Wikipedia discussion pages - I don't particularly mind that because there is no convenient alternative and discussion pages aren't as widely read as articles. But on articles, it shouldn't be there. An obvious exception is the article strikethrough. Graham 87 02:22, 25 October 2007 (UTC)
I'm curious; does Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text apply to hide/show buttons like used in infobox templates and templates displayed at the bottom of articles? (f.e at the bottom of Heavy metal music and the Tom Cruise infobox). Because this hide/show functionality is just a cascading style sheet trick I always thought content hidden this way is still picked up by screen readers etc.. (and when copy-pasting hidden text the hidden text is put on the "clipboard"). In other words, is this hide/show functionality an accessibility issue? Cheers Kameejl ( Talk) 10:33, 29 October 2007 (UTC)
There has been some discussion on Talk:Blink element about whether there should be a working example (as opposed to just showing the source code for an example). I've argued that if there needs to be an example of what blinking text looks like then it should be done with an image rather than the blink element so as to ensure maximum support (similar to how the examples in the SVG article are actually all PNG files generated from the original uploaded SVG). However, in an article with several paragraphs about the accessibility concerns arising from having any blinking content, it would be rather ironic to include such an image. As the issues of blinking text doesn't seem to be covered in any Wikipedia guidelines, I thought I'd ask here for advice. — Safalra ( talk) 14:04, 17 November 2007 (UTC)
I've added two suggestions from the WP:MOS about image placement, and sizing. Forcing sizing (which over-rides user's set preferences) is not advised without a good reason, because for readers who use a large font, and low resolution, it can cause display issues. Additionally, placing images underneath second level headers (===) causes display issues as well. I added those two things, and placed a link to the Images section of the manual of style. (I've verified both issues with both Firefox, and IE7, using a low resolution and oversized font, and confirm there are problems with forcing sizing for those with vision problems). Hope that's helpful! Ariel ♥ Gold 10:26, 18 November 2007 (UTC)
I have marked the Wikiproject Directory as having an accessibility problem because the tables use color as the only means of conveying whether or not a project is active. To join the discussion, see Wikipedia talk:WikiProject Council/Directory#Accessibility Problem. Thanks, L'Aquatique talk 21:26, 24 November 2007 (UTC)
The Random Acts of Kindness Barnstar | ||
To Kirill for going out of your way to fix the accessibility problem at Wikipedia:WikiProject Council/Directory. Your efforts have helped to make Wikipedia more accessible for all. Many thanks! l'Aquatique talk, Jeepday ( talk) |
What we call tooltips is in fact the standard title
attribute of an element. Is it actually known that a physical action is required to show these in all browsers? Or could some user-agents e.g. speak them along with the rest of the text. Use of e.g. <abbr>
which uses the title text is specifically recommended by many other authorities, explicitly for accessibility purposes. —
Random832
18:16, 3 December 2007 (UTC)
But what is the status of such tooltips. Screenreaders may not read them out loud, but then, if there is a link to a more explanatory document closeby, it should be fine. In the case of the template R-phrase, these links are almost exclusively used next to a wikilink (like: " R-phrases: {{R1}},{{R2}}", see e.g. Methanol, in the box on the right hand of the page, hazards section). For the majority of people the tooltips are an easy way of getting more information, though for people who have access to the tooltips, as well as those that use a screen-reader, the wikilink to what R-phrases are is next to it. In the post by Graham87 is a link to JAWS. I don't know what JAWS is, so I have to actually click the link, so that is not different from the situation as it is for people using a screen reader. Tooltips just provide a bit more on-hands information, though they should/must be used on elements where an explanatory wikilink is nearby. -- Dirk Beetstra T C 18:41, 6 December 2007 (UTC)
Expanding on this, making things more accessible would be that all wikilinks in a document would support the element of a one-liner tooltip which quickly gives more information on what lies behind it (e.g. first sentence of the document linked to), not in discouraging or forbidding the use of tooltips altogether. -- Dirk Beetstra T C 18:50, 6 December 2007 (UTC)
title
atrribute. As far as I know, in most browsers the only way to access this is by mouse hovering, but Random is right to ask that we find out exactly how screen readers do deal with them. In contrast, to follow a link you do not have to click on it. In most browsers, you can use the keyboard to tab through the links, without using the mouse (which requires much better motor control) at all. We can also assume that screen readers and so on have appropriate methods for following links, as following links is/has been a more fundamental aspect of web browsing than viewing title
attributes for a long time.title
attribute was used explicity to produce tooltips because "it would be nice to have the textual descriptions of these as well" but "I suppose that would take too much space". If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal. If it is a solution to a real problem concerning how to fit in necessary information, then there is something wrong, as the problem is still present for some users, but the partial solution means few people are aware of it. (In this particular case, the use of the templates in the context of a wikilink is relevant to this distinction, but I am not trying to make an argument for or against these templates, rather trying to use them as an example to explain the issue.)<abbr>
, as this would allow the use of tooltip while at the same time using the recommended HTML for abbreviations, which should be utilised by more and more accessbility software.
JPD (
talk)
12:17, 7 December 2007 (UTC)I think indeed that it should be in such a way that "If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal." In the R/S-phrase case in a way it is a problem there, the full sentence does not fit in the box .. but then, if you take out a catalogue where they sell chemicals, they only show 'R 1,5,7,9' as well and you have to browse to the index to find what is what. But since Wikipedia is not a paper encyclopedia, we can use features which are not possible on paper, as long as we make sure that anyone can access the information. And I believe that is the case in the R/S-phrase case. Maybe in the guideline here it should say, that tooltips/hover-texts are discouraged, but if they provide easier, hands-on information that they can be used when they do also provide a link (closeby) to more information so everyone can get to the information.
The rest would be an extended function of the mediawiki software, which would be a nice gadget. We don't have that, so that part of the question is more for Village pump, or bugzilla. -- Dirk Beetstra T C 12:44, 7 December 2007 (UTC)
I've used sometimes and contributed to/created the templates {{ abbr}} and {{ abbrlink}} (but they are somewhat experimental) as a way to fix the lack of the HTML <abbr> tag — a tag which can improve accessibility. [7] My idea was to create these templates so people start using it, and meanwhile submit a bug report. [8] Finally, when MediaWiki supports this HTML tag my plan was to modify these template using the <abbr> tag instead of a tooltip. Hope this helps — surueña 22:00, 9 December 2007 (UTC)
Over on the various Amazing Race season pages (such as The Amazing Race 12), we have a series of icons that reflect tasks that are done on the show. The images (from Commons, and placed through templates) have alt text to describe the icon, and just recently we are adding a key to what the images are for those completely unfamiliar with the show (as see at the start of this section. One editor suggested that via accessibility, this may not be strictly appropriate since we're using images to convey information. I would like to check if there's any problems with this approach and if we need to consider something else. -- MASEM 00:07, 8 December 2007 (UTC)