Jump to content

Talk:Accessibility Initiative

From Wikimedia Usability Initiative
Latest comment: 13 years ago by in topic Screen reader survey

IRC channel

moved from Accessibility Initiative

Rather than adding yet another irc channel to keep track of, why not use one of the current low-traffic Wikimedia channels? This would be appropriate for #wikimedia, #wikimedia-tech, or a more general #wikimedia-design or #wikimedia-usability channel (which would encompass accessibility, visual aesthetics, initial barrier to entry for various participants, expert usability and efficacy, use of scripting to improve individual productivity, &c.). Sj

There are couple points why own channel is better solution:

  1. Channels with high traffic are crowded and it's hard to follow the thread when more people discuss more topics.
  2. We already experienced some long discussions which proved there will be such in the future and I guess, that other (rather general) channels wouldn't be happy if we cluttered them with our detailed talks.
  3. Dedicated channel makes logging and therefore searching for information easier.
  4. Easy to distinguish involved/interested people which is on "shared" channel impossible.
  5. other...

Danny B. 07:14, 27 April 2010 (UTC)Reply

  • The channels I suggested have low traffic. The general dilemma across most Wikimedia channels and mailing lists today is the lack of traffic and the difficulty in discovering what is going on where. Recentchanges helps avoid this, and was an essential innovation in wikis; we need something similar for other channels. Until we have it, it's not a bad idea to start conversation *where people are* rather than creating a new space and asking a few friends to move there, away from existing spaces
  • Wait until you have complaints from existing channels before moving, don't predict :)
  • Logging... searching... where are these things set up? Creating a 'logged channel' is a fine reason to start something new, but you can have many topics within a single logged channel (search is clever :)
  • It's not easy to distinguish involved/interested/alive people on "dedicated" channels either! I'm not sure that it is worth making it hard to find/listen to accessibility discussions, simply to add another broken metric for activity.
Sj 18:50, 27 April 2010 (UTC)Reply

Hello sj, first of all: Welcome to the Wikimedia Accessibility Initiative (WAI). ;) Apart from the arguments you exchanged with Danny, I want to add that we have a problem with the different time zones, that is independent from which channel we use. You said we should have discussions where people are. I agree with that, but please note that I, for example, have never been to #wikimedia or any other channel you mentioned. #wikimedia-usability would be the most fitting channel from your suggestions, but that doesn’t meen abandoning #wikimedia-accessibility. The latter has worked for me so far, but you might be right that it’s an extra barrier when we want to involve people. Lecartia 06:29, 28 April 2010 (UTC)Reply

Presentation at Wikimania

Is anybody going to Wikimania in Poland? Unfortunately, I can’t go because I have to attend a conference in Austria. I’d love to see somebody giving a presentation/talk/demo etc. on accessibility at Wikimania. The deadline for submitting proposals ends on 20th of May (see Wikimania Call for Participation). Lecartia 07:13, 29 April 2010 (UTC)Reply

Sure, that's a great idea! In the Call for Participation/plain text, accessibility is mentioned in the "Infrastructure Track" section. Looks like they want us to make a talk about accessibility. :-) Maybe I could go, I'll think about it. Dodoïste 13:26, 29 April 2010 (UTC)Reply
I believe it's the best way to contact the Foundation. We'll have both the occasion to convince them, and a chance to talk about the necessary decisions they have to take in order to improve accessibility. Is someone going with me? I'd hate to be the only one guy who cares about accessibility at Wikimania. If' we're at least two we'll have more impact. Yours, Dodoïste 11:21, 30 April 2010 (UTC)Reply
I could re-arrange my work schedule and will now also attend Wikimania. I will link to the proposed presentations/workshops on the WAI page. Lecartia 06:59, 12 May 2010 (UTC)Reply

In-page readers

I'm not sure in-page readers would really improve accessibility. It is not a requirement to meet the standards. An accessibility expert to me that it's not a priority. Since blind users on the Web have their own screen reader, how would such a feature help? Yours, Dodoïste 14:36, 7 May 2010 (UTC)Reply

Hi Dodoïste, my idea is not about meeting standards, but about providing access to blind people who are not so fortunate to have assistive technology available, mostly in developing countries. I am sure sj could explain this need concretely in connection with the One Laptop per Child project. Lecartia 23:47, 8 May 2010 (UTC)Reply
OK. Yes, I'd love to have details about it. Some free screen readers like NVDA are available, so why not provide NVDA on the One Laptop per Child project? Firevox is not optimal because it only works within Firefox, but I believe NVDA is quite good. Yours, Dodoïste 01:38, 9 May 2010 (UTC)Reply

Thread on foundation-l

Hi, I'm interessed in this initiative, but I have an other urgent project this month. I just mention the thread "[Wikitech-l] Visual impairment" on Wikitech-l and Foundation-l these days. ~ Seb35 [^_^] 12:54, 16 May 2010 (UTC)Reply

For info, here is the link to the "Wikitech-l Visual impairment" thread archive. Dodoïste 20:29, 27 May 2010 (UTC)Reply

Dive into Accessibility - Wikipedia

Hi! I got a bit interested in this when I heard about it on the strategy wiki. I therefore read through the "Dive into Accessibility" webpage and tried to use that to analyze Wikipedia. Don't know if it is of any interest, especially as I suspect that the information might be somewhat deprecated. But anyway, here are my comments:

Accessibility requirement Implemented on Wikipedia?
Day 6 - Choosing a DOCTYPE: Yes
Day 7 - Identifying your language Almost, but not exactly (Wikipedia does not have the xml:lang="en" parameter, only the lang="en" parameter).
Day 8 - Constructing meaningful page titles Yes
Day 9 - Providing additional navigation aids There is no <link rel="home"> tag on Wikipedia, could easily be implemented. Neither are there "prev" and "next" links, but I am not sure there is any reason for implementing these on Wikipedia. For other projects with multiple page articles these might however make sense.
Day 10 - Presenting your main content first Not clear to me if this is done in an optimal way. (Think this one is worth researching)
Day 11 - Skipping over navigation links Has to be considered in connection with Day 10
Day 12 - Using color safely Links can appear as ordinary text to color blind. The solution to decorate the links that is given in the book is probably not feasable for Wikipedia. So is there any other possible solution?
Day 13 - Using real links There is javascript on Wikipedia, but I don't find any javascript links as those described in this problem. So at least to this extent this seems to be satisfied on Wikipedia.
Day 14 - Adding titles to links Don't know if this is done satisfactory on Wikipedia. Many links do have title. Among those that not have are the interwiki links between different language versions in the Vector skin (I guess this is very simple to fix if it is wanted), and also some external links that are added by editors.
Day 15 - Defining keyboard shortcuts Yes (if any additional shortcuts should be included could surely be discussed though). Maybe "skip navigation link" is something that should be implemented, this is related to day 10-11.
Day 16 - Not opening new windows Yes
Day 17 - Defining acronyms For reader of Wikipedia I don't think this is a problem. But on discussion pages I think this is a real problem for new users (http://en.wikipedia.org/wiki/Wikipedia:Acronyms).
Day 18 - Giving your calendar a real caption
Day 19 - Using real table headers
Day 20 - Providing a summary for tables Wikitables allows for summaries, but does not require them. If this is important, I guess it would be a quite easy task to write a bot that goes through all Wikipedia articles and collects information about which tables are in need of summaries.
Day 21 - Ignoring spacer images Seems to be satisfied.
Day 22 - Using real lists (or faking them properly) I think this is satisfied.
Day 23 - Providing text equivalents for images The image tag (http://en.wikipedia.org/wiki/Wikipedia:Images) does have an alt parameter, but it doesn't seem to be used very much. A similar bot as that for the table summary problem of day 20 could probably be written here. Maybe empty alt parameters could be replaced by an approperiate standard text.
Day 24 - Providing text equivalents for image maps
Day 25 - Using real horizontal rules (or faking them properly)
Day 26 - Using relative font sizes ?
Day 27 - Using real headers ?
Day 28 - Labeling form elements
Day 29 - Making everything searchable Yes. Does however recommend accesskey="4" instead of accesskey="f".
Day 30 - Creating an accessibility statement No?

--Dafer45 18:25, 26 May 2010 (UTC)Reply

Hello Dafer45, many thanks for your efforts! I will have a look at that in detail later and try to fill the gaps. Lecartia 09:01, 1 June 2010 (UTC)Reply
I am one of the two experts who gave a talk about Wikipedia and accessibility at Paris Web 2009, as mentioned on this submission for the next Wikimania.
This check-list was written at a time WCAG were in their 1.0 version -back to 1999. The Web has evolved since, ant the WCAG 2.0 now provide many new examples of best practices. For example, providing titles to links is no longer a strict requirement, as the context of each link should be taken into account. Keyboard shortcuts, a big #fail of Web accessibility, are no longer necessary, etc. There are a few of other points here that are not mandatory.
Most important, this is not really how the source code is organized and can produce accessible content which has a major impact on the effective accessibility of a page. It is the way contributors do produce content which is the main source of accessibility problems. You may have the most efficient CMS in the world, the fact is, that if your content producer writes a tag soup, it will remain a tag soup until someone else comes and corrects it. Litlok 11:58, 1 June 2010 (UTC)Reply

Hi, Litlok, it’s great to see you here. I hope MediaWiki’s (missing) accessibility will get lots of chances to profit from your expertise. I hope you or Dodoiste can give the WMF some figures on this topic, especially on “It is the way contributors do produce content which is the main source of accessibility problems.” Lecartia 13:24, 8 June 2010 (UTC)Reply

Wikimédia France and blog post

Hi, last Tuesday we discussed between members (not at a Board-level) about projects Wikimédia France could lauched and an idea was to support accessibility projects like this project and/or the Orca project (it's just ideas for now). So if WMFr could do something for the WAI, please say it (email me if I don't respond) and I could propose to the WMFr Board a precise project, possibly shared with other chapters and/or the Foundation.

Seb35, this can be an excellent idea. I (as acting for Wikimedia Deutschland) like to see concrete projects together with other chapters and the foundation. Seb35, is there any chance you are attending Wikimania in Poland? I’d like to talk about this and spin aorund some ideas. Lecartia 09:12, 1 June 2010 (UTC)Reply
Yes, I attend to Wikimania (and Dodoïste!). I arrive Tuesday 6 July in the Wikipedia:Meetup/Wiki-train and Dodoïste should come by airplane Thursday 8. ~ Seb35 [^_^] 22:14, 14 June 2010 (UTC)Reply

For now I have another subject to submit you: I've written a blog post for the Wikimedia France's blog which speaks about this initiative in order to broad its existence. Could you check it and comment it (http://typewith.me/dH462zjszH) ? because I am interested in the accessibility questions but I am still novice in the domain, and your experience would be beneficial (I translated it into English). ~ Seb35 [^_^] 11:39, 29 May 2010 (UTC)Reply

Hello Seb35, I commented on your longdesc questions there. In a nutshell: No one really uses it and its poorly supported by AT. I am hoping for aria-describedby which can be text or an URL/a reference to be much more successful. Are there any other questions arising from your blog post? Lecartia 09:12, 1 June 2010 (UTC)Reply
As adviced also Lgd on [1], I removed this paragraph on longdesc. It's true it's a difficult subject and it's better not mention it on an all-public post. The post has been published yesterday [2] (en) (de) (die deutsche Übersetzung ist nicht so schlecht aber die englische ist besser). ~ Seb35 [^_^] 22:14, 14 June 2010 (UTC)Reply

Screen reader survey

The two surveys about screen reader users from 2009

seem very helpful. Captchas, e.g., are still number one problem. Lecartia 07:35, 22 June 2010 (UTC)Reply

Sadly we're one of the problems there. 00:47, 24 October 2010 (UTC)Reply

strategy:Regional bandwidth

I think that you may be interested in this. I've created a category, please help me categorize relevant pages on strategy wiki (proposals should be already categorized). --Nemo 04:12, 16 August 2010 (UTC)Reply