Talk:Accessibility/Archive 1
Word choice
editTo the anonymous user who contributed the section on "vocabulary matters" -- I agree that the avoidance of jargon or obfuscated language is a good idea, but it seems that this point belongs on w:Wikipedia:Explain jargon or a related editing policy page. Since this is meta, I intended the accessibility discussion to be mostly about what we will recommend on normal policy pages, how we can go about improving the existing guidelines or policies, implementing any necessary changes in the software, etc. -- Wapcaplet 13:30 1 Jul 2003 (UTC)
Ugh. Something just occurred to me. The indentation we use (mostly in talk pages but in lots of articles too) by inserting a colon ":", or several, at the beginning of a line, ends up mapping to a definition list in the resulting HTML. Worse, it's a "definition list" with no terms, and all definitions. i.e.:
:indented stuff
turns into:
<p><dl><dd>indented stuff</dd></dl>
Plus there's that "empty" paragraph to start it off (since paragraphs cannot contain other block-level elements, including definition lists). I do not know if this relates directly to accessibility, but it's a good example of poor use of semantics. We shouldn't be using definition lists just to format text. Blockquote would be the next best thing, but multiple-indentation gets tricky then. Blockquote shouldn't really be used for indentation either, unless the text contained within it really is a "block quote" of some kind. On talk pages or anywhere else indentation is used a lot, I would suggest the following (if it's not too hard to implement in the PHP scripts):
:indented stuff ::even more indented stuff
turns into:
<p style="margin-left: 4em;">indented stuff</p> <p style="margin-left: 8em;">even more indented stuff</p>
If 4em isn't enough, maybe more (it looks like the current indentation is somewhere around 4, though). The only potential problem I can see with this is that it's still not too semantically meaningful, and will not be indented on browsers without CSS support. It doesn't seem that HTML provides any kind of semantic mechanism for the newsgroup-style indentation we use on talk pages, though. Anyone know of a better solution?
-- Wapcaplet 13:15 2 Jul 2003 (UTC)
It seems to me that <blockquote> is precisely the HTML equivalent of newsgroup-style indentation (indent text that is a quote from someone else's post to which you are replying), but that's not what we're doing here (indent your additional post to mark it as a response to the above text).
Now, the cleanest thing that could be done would probably be to just use <div>s. So:
Surrounding text :Indented text ::More indented text :Previous level of indentation More surrounding text
becomes:
<p>Surrounding text</p>
<div class="indent">
<p>Indented text</p>
<div class="indent">
<p>More indented text</p>
</div>
<p>Previous level of indentation</p>
</div>
<p>More surrounding text</p>
Speech browsers that use auditory stylesheets could make useful distinctions on this system (begin/end cue sounds, or alter the voice quality for each successive level), but I don't know if that's something that's actually supported at present. In lynx we'd lose all indentation information.
So, looks like we can either use proper stylesheets and lose some support, or abuse markup that's not quite what we want: blockquote or lists of some type. --Brion VIBBER 04:53 3 Jul 2003 (UTC)
Main template accessibility issues
editHello, I've made a list of accessibility issues with the current main template (ignoring the obvious tables for layout/stricter HTML). These are my personal opinions, so feel free to disagree or comment :)
- <body> is set to have a white bgcolor, but no text color. If a visual browser has no CSS support and the default text color is white, pages are invisible. I would suggest specifying no background or text colors, leaving it up to the user. However if either is specified, the other always should be.
- The target of a link is currently only conveyed in color (blue for internal, red for non-existent pages, light blue for external), so the user would not be able to tell where the link goes if unable to see the color (unless they set up a user stylesheet). Information about the target URL could be added to the title attribute, or other non-color styling could be used.
- The order of elements within the markup is generally poor. The logo should ideally be right at the start of the page (it's currently after the content), with alt text of "Wikipedia" or "Wikipedia - The Free Encyclopedia". It's very important to have clear branding so users are well orientated and do not get lost.
- Jump to navigation or content links could be added, they're handy for screenreader and keyboard users, and they don't have to clutter up the visual appearance of pages if hidden until selected.
- Search box has no label, screenreader users could be confused as to what it is. Adding a title attribute may make it clearer.
- Titles added to links should be carefully considered, especially repeating navigation ones. For instance "Special:Recentchanges" could be read by a screenreader, and would make much less sense than the link's text of "Recent changes".
- Paragraph elements should not be empty, but always contain text. This may be hard in articles, but should be corrected within the main template at least.
- Suggestion: add a CSS signature to <body> element, so user stylesheets can easily be applied.
- More than one <br> should not be used next to each other. This happens in the main template, paragraphs should be used instead.
- For the navigation bar, might be better using an unordered list, instead of line breaks. It could keep the current visual appearance via CSS.
Tom- 00:20, 11 Mar 2004 (UTC)
- Most of these things are implemented now in the MonoBook skin. See User styles as well for some ideas on what you can customize now if you need to (you can use css and js, so you can change really anything). -- Gwicke 23:44, 13 Jun 2004 (UTC)
Rename proposal
editThe page is misnamed, I think: The concept of having projects accessible to all users extends past Wikipedia itself to all WMF projects (limited there only due to the scope of the discussion).
I'd like to propose renaming the page to Accessibility over the newly-created redirect. Sukida 20:38, 4 March 2010 (UTC)
- I support this. Tisane 06:29, 7 March 2010 (UTC)
Done — Mike.lifeguard | @en.wb 13:31, 7 March 2010 (UTC)
Colour-blind-friendly images
editI've added such a section because I think this is an area where we lack guidelines and tool fit to the purpose. None of the illustrations I see on Commons seem to care about this, and a lot of work is needed to fix them. But I think it's feasible, with the correct tools. I've also asked around with some e-mails to people involved in colour accessibility and posted a question on w:en:Wikipedia talk:WikiProject Maps#Colour-blind users and commons:Commons talk:Graphic Lab#Colour-blind users. Nemo 20:17, 1 January 2013 (UTC)
Book Review: Digital Outcasts
edithttp://books.slashdot.org/story/13/11/25/1425239/book-review-digital-outcasts A summary/bookreview that you might find interesting. Quiddity (talk) 20:08, 28 November 2013 (UTC)
Templates vs screenreader
editSit next to a blind person trying to navigate a wikipage. Every single template at the top of the page is read out at 200+wpm before you ever get to content. (and where it starts is not immediately clear either. I have no idea how these folks have the patience to live with it. :-/ --Kim Bruning (talk) 19:49, 30 March 2014 (UTC)
Linkdump - accessibility and usability
editmw:Accessibility and usability cleanup - hopefully useful for any of us that engage in cleanup work over the coming [timespan]. I think it lists all the main pages, but please add anything I've missed. Quiddity (talk) 20:25, 27 July 2014 (UTC)
Palette generator
editThis tool seems useful: http://tools.medialab.sciences-po.fr/iwanthue/ (via [1]). I've not tested it extensively though. --Nemo 19:35, 25 November 2017 (UTC)
Mediawiki treating ":" markup as definition list markup when it's not a list badly needs to get fixed
editPlease see w:en:Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation.
The gist: because MediaWiki isn't smart enough to tell when a line starting with : is a <dd>...</dd> or not (which is a simple regular expression to detect whether it's immediately preceded by a line starting with ; for <dt>...</dt>), it always emits <dd>...</dd> markup even when it should obviously be using <span>...</span> with padding-left to produce an indent in absence of there actually being a description list. This is a nasty accessibility problem.
Because the : markup is easy and quick, and because the average editor neither understands nor cares about accessibility issues, the RfC in question appears poised to quite literally refuse to permit more accessible markup, even in Wikipedia articles (we don't care much about talk page usage, a lost cause until we get threaded discussion software that also handled MW markup examples correctly).
This is stunningly, almost unbelievably short-sighted, confused, and lazy, but it is happening right now.
The MW developers have been asked to fix this simple and obvious problem for over a decade (bug T6512, dating to 2006 on the original bug tracker, and itself based on earlier ones), but they have not done so. How is it possible that an organization with tens of millions of dollars and a big development team working primarily on a single piece of software cannot get it together and fix a problem this basic? This should be resolvable within the month.
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:41, 4 December 2017 (UTC)
ADA lawsuit
editLefkowitz v. Google filed. Surprisingly, it's focused on what I'd consider extremely minor software defects, while it doesn't say anything about way worse and potentially insourmountable issues like ReCAPTCHA. Nemo 19:29, 26 October 2019 (UTC)