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)
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)
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)
- See also mw:Talk:Accessibility#Colour-blindness links and notes. Quiddity (talk) 20:09, 28 November 2013 (UTC)
Book Review: Digital Outcasts
http://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
Sit 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
mw: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)
Mediawiki treating ":" markup as definition list markup when it's not a list badly needs to get fixed
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
<dt>...</dt>), it always emits
<dd>...</dd> markup even when it should obviously be using
padding-left to produce an indent in absence of there actually being a description list. This is a nasty accessibility problem.
: 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)
Lefkowitz 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)
Some more resources
https://www.gov.uk/service-manual/helping-people-to-use-your-service/testing-for-accessibility seems a useful page. However I've not yet tested their suggestions. If someone knows them, please add to the subject page. Nemo 08:29, 7 February 2020 (UTC)
Request for accessibility specifications
So it seems like the place to centralize further discussion on accessibility
@Nemo bis, Eric Luth (WMSE), WikiLucas00, André Costa (WMSE), Tanzania, Sebastian Berlin (WMSE), John Andersson (WMSE), Marcus Cyron, Stryn, Dikgosi Sejabodile, Marajozkee, Ivanhercaz, ZI Jony, Ainali, Kaizenify, So9q, DannyS712, Karl Wettin (WMSE), and Iran11y:, following @Bluerasberry: message in Talk:Community_Wishlist_Survey_2021/Reading/Increased_accessibility, after I erroneously modified previous Wishlist Survey in my enthusiasm to follow the recommandation of @Alexcalamaro: in Talk:Accessibility of Wikipedia, a March 2021 use test session.
I don't know when will be the opening of the next Wishlist Survey, but surely a lot can be done already before that. If something is easy to implement, as the bypass for the footnote references, then maybe it's not necessary to wait for the Wishlist to come back. If no one else with more accurate skillset has time to do so, I might have a look to make a prototype in the coming weeks/months, depending on my own schedule. I didn't play with a local Mediawiki installation for a while, and I don't think I already went through a whole process of extension creation for it, so someone who already has theirs hands frequently under its wood would certainly be able to come more quickly than me with a functional prototype. But at worst I think I do have the required background to achive that on my own, and without a doubt that's a topic I consider worthwhile of my time. So at very least, if someone is willing to play as a mentor of me hacking a bit of Mediawiki, this would be warmly welcome.
Last but not least, all my apologies, I mass pinged you a lot this week. I plane to stop doing so with this message, at least for those who don't explicitly ask for further ping from me on this topic. Kind regards, Psychoslave (talk) 19:32, 28 March 2021 (UTC)
A Wikimedia Hackathon 2021 session on accessibility
Hello, @Nemo bis, Eric Luth (WMSE), WikiLucas00, André Costa (WMSE), Tanzania, Sebastian Berlin (WMSE), John Andersson (WMSE), Marcus Cyron, Stryn, Dikgosi Sejabodile, Marajozkee, Ivanhercaz, ZI Jony, Ainali, Kaizenify, So9q, DannyS712, Karl Wettin (WMSE), and Bluerasberry:
I just wanted to let you know that I submitted a session proposal for this year hackathon on accessibility. The corresponding ticket is named [Session] Accessibility: state of the art, what is already good, what can be improved and any feedback is welcome there.