To 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.:
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
<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
<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 
Hello, 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 
The 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 support this. Tisane 06:29, 7 March 2010 (UTC)
Colour-blind-friendly images 
I'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)