| Revision as of 23:31, 6 June 2013 editWhatamIdoing (talk | contribs)Autopatrolled, Extended confirmed users, Pending changes reviewers121,699 edits →RFC at WT:ACCESS: new section← Previous edit | Revision as of 01:03, 7 June 2013 edit undoWhatamIdoing (talk | contribs)Autopatrolled, Extended confirmed users, Pending changes reviewers121,699 edits →VisualEditor is coming: new sectionNext edit → | ||
| Line 232: | Line 232: | ||
| There is a discussion at ] about whether accessibility should be encouraged for talk pages, project pages, etc., or just for articles. ] (]) 23:31, 6 June 2013 (UTC) | There is a discussion at ] about whether accessibility should be encouraged for talk pages, project pages, etc., or just for articles. ] (]) 23:31, 6 June 2013 (UTC) | ||
| == VisualEditor is coming == | |||
| The ] is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka ]), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs '''currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013'''. | |||
| A couple thousand editors have tried out the early test versions so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will '''not''' be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that ] is ultimately supposed to deal with talk pages). | |||
| The developers are asking editors like you to join the alpha testing for the VisualEditor. This is especially important for people who deal with accessibility, because it always takes a while to write, test, and deploy code—so it's important to get any major problems on the list sooner rather than later. ''Please'' go to ] and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the ''top'' of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note ] about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar. | |||
| Also, the screenshots and instructions for basic editing will need to be completely updated. '''The old edit window is not going away''', so help pages will likely need to cover both the old and the new. The WMF is committed to this long-requested improvement, and it's my impression that nothing short of a complete collapse of the servers will cause it to be reversed, so we need information that will help them get it right. The new editing system will become the default, not the only option. | |||
| If you have any other questions and can't find a better place to ask them, then please feel free to leave a message on ], and perhaps together we'll be able to figure it out. Thanks, ] (]) 01:03, 7 June 2013 (UTC) | |||
Revision as of 01:03, 7 June 2013
| This is the talk page for discussing WikiProject Accessibility and anything related to its purposes and tasks. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8Auto-archiving period: 6 months  |
 | Accessibility | |||
| ||||
| This is the talk page for discussing WikiProject Accessibility and anything related to its purposes and tasks. |
|
| Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8Auto-archiving period: 6 months |
| WikiProject Accessibility |
|---|
| Article guidelines |
| Template guidelines |
| Coordination |
| For impaired users |
WebAIM Survey of Preferences of Screen Readers Users
A preliminary summary of results from WebAIM's Survey of Preferences of Screen Readers Users has been published. —Michael Z. 2009-02-02 05:13 z
Template:Fraction
I believe that Template:Fraction fails MOS:FRAC and WP:NOSYMBOLS because of its use of Unicode fractions, and also its use of the Unicode character ⅟ to represent certain fractions with unit numerator. Consider the following:
{{fraction|1|2}}→ 1⁄2{{fraction|1|3}}→ 1⁄3{{fraction|1|4}}→ 1⁄4{{fraction|3|4}}→ 3⁄4{{fraction|1|5}}→ 1⁄5{{fraction|1|6}}→ 1⁄6{{fraction|1|8}}→ 1⁄8
Potentially, constructs such as these could yield any of the following: ½, ⅓, ⅔, ¼, ¾, ⅕, ⅖, ⅗, ⅘, ⅙, ⅚, ⅛, ⅜, ⅝, ⅞.
Constructs where the numerator is 1 but the denominator is not 2, 3, 4, 5, 6 or 8 yield the ⅟ character:
{{fraction|1|7}}→ 1⁄7{{fraction|1|9}}→ 1⁄9{{fraction|1|10}}→ 1⁄10{{fraction|1|100}}→ 1⁄100{{fraction|1|1000}}→ 1⁄1000
But other fractions where the denominator is not 2, 3, 4, 5, 6 or 8 come out like this:
{{fraction|2|7}}→ 2⁄7{{fraction|2|9}}→ 2⁄9{{fraction|2|10}}→ 2⁄10{{fraction|2|100}}→ 2⁄100{{fraction|2|1000}}→ 2⁄1000
By contrast, the {{frac}} template consistently uses <sup></sup>⁄<sub></sub> as in:
etc. --Redrose64 (talk) 21:59, 5 July 2012 (UTC)
- I still don't understand why commonly-used fraction characters aren't supposed to be used. First of all, calling them "Unicode" is incorrect; vulgar one-half, one-quarter, and three-quarters are part of ISO-8859-1. I'd like somebody to give me an example of a single browser or screen-reader nowadays that won't support them. It's silly that we're still using these hacky workarounds.
- I agree with your other point, however. The fractions that don't have characters should be formatted more consistently. That would be an easy fix in the template.—Chowbok ☠ 10:14, 6 July 2012 (UTC)
- Redrose64's reasoning is correct. But I feel I am not the right person to answer this question, as I don't use a screen reader everyday. We should ask for user:Graham87's advice on the matter. Unfortunately, he just left to attend Wikimania, and won't be back before some time.
- In the meantime, I tested using Apple's VoiceOver. I was able to read everything, but not too well. ½ was correctly read as "one-half"; same with the following fractions of this type. But as I tried to read the whole list "½ ⅓ ⅔ ¼ ¾ ⅕ ⅖ ⅗ ⅘ ⅙ ⅚ ⅛ ⅜ ⅝ ⅞", VoiceOver crashed. I tried with my Chrome native text to speech, it crashed and I had to restart Chrome. Oh boy.
- 1⁄1000 behaves weirdly. It is read "one one thousand", but no indication of it being a fraction (or am I not used to hear english fractions?). If I read "⅟" alone it is read "one fraction symbol".
- 2⁄7 is read as "two slash three".
- 3⁄4 is read as "three four".
- Frankly, I do not know how to interpret these result. Plus, this is only VoiceOver. Hoes does JAWS and NVDA behave? I don't know. Let's wait before we take a decision. Dodoïste (talk) 11:43, 6 July 2012 (UTC)
- Both JAWS and NVDA read only the ISO 8859-1 characters correctly, not the Unicode ones. I'm writing this from a lovely hotel room in Toronto. I plan to check my watchlist every few days if I can. Graham87 02:12, 8 July 2012 (UTC)
Why do we need two templates, {{fraction}} and {{frac}}? How are the majority of editors supposed to understand the difference between them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:06, 26 July 2012 (UTC)
- Apparently we now have three, see
{{Sfrac}}. --Redrose64 (talk) 15:09, 26 November 2012 (UTC)
Potential collaboration/taskforce/WikiProject
Gauging interest I am posting the same message to Misplaced Pages talk:WikiProject Images and Media, Misplaced Pages talk:WikiProject Usability, and Misplaced Pages talk:WikiProject Accessibility to see if there is interest in a collaboration regarding adding subtitles to audio. Recently, the TimedText namespace became active and I decided to test it out with two subtitles: TimedText:Sufjan_Stevens_-_Casimir_Pulaski_Day.ogg.en.srt for File:Sufjan Stevens - Casimir Pulaski Day.ogg and TimedText:They_Are_Night_Zombies!!_-_Sufjan_Stevens_-_clip.ogg.en.srt for File:They Are Night Zombies!! - Sufjan Stevens - clip.ogg (someone else has created TimedText:Björk_-_Mutual_Core_sample.ogg.en.srt for File:Björk - Mutual Core sample.ogg as well.) I also worked with Rich Farmbrough (talk · contribs) to create {{Subtitles}} and categorize audio files with subtitles. This leaves 7,087 audio and video files which lack subtitles (note that not all need them as some have no spoken audio.) Does anyone want to help me? —Justin (koavf)❤T☮C☺M☯ 19:18, 5 November 2012 (UTC)
Template:Access icon
Template:Access icon has been nominated for deletion. Please comment at Misplaced Pages:Templates for discussion/Log/2012 November 12#Template:Access icon. --Redrose64 (talk) 16:00, 12 November 2012 (UTC)
Wikivoyage:Accessibility
Like Wikidata:Accessibility, above, I have added a Wikivoyage:Accessibility project to Wikivoyage. No doubt our new colleagues there will appreciate your input. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:36, 14 November 2012 (UTC)
FAC review headings
I've raised a concern about WP:FAC, which says "Please do not split FAC review pages into subsections using header code (if necessary, embolden headings)", as this is contrary to WCAG. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:47, 21 December 2012 (UTC)
RfC: Section headings for horizontal navigation templates
Please comment on accessibility considerations, at Misplaced Pages talk:Categories, lists, and navigation templates#RfC: Section headings for horizontal navigation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:04, 28 December 2012 (UTC)
Headings in Portal:Current events
I've raised a concern about sub-headings in Portal:Current events, which are formatted using semi-colons. Your comments would be appreciated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:32, 28 December 2012 (UTC)
Question regarding "Disabling conditions" and competence of editors
Please see here for a question I believe may well be relevant to matters of accessibility of wikipedia editing by certain editors, known and unknown. Any response would be welcome. John Carter (talk) 02:07, 10 January 2013 (UTC)
Inline tags
Some in the German Misplaced Pages are discussing (at length!) whether they should introduce a template, equivalent to Citation needed. A contra-argument that has been raised now is the possible accessability barrier of inline tags, like those emitted by {{Citation needed}}. However, there seems to be limited experience there to determine whether that is so or not. Does the output of this template have an effect on accessability? Can screenreaders be configured to lessen the effect? Was there evere a discussion where accessability issues were raised against inline templates? -- Michael Bednarek (talk) 05:24, 10 January 2013 (UTC)
- There's very little wrong with inline tags from an accessibility perspective. The links provided with the tags are a little annoying for screen reader users (as they should be), but its possible to lessen the effect of that issue if needed. Graham87 12:48, 10 January 2013 (UTC)
Keyboard accessibility of article feedback tool
I cannot find any way to give star ratings to articles without using a mouse. The rating widgets don't seem to be in the tab order in any of the browsers I've tried; additionally, although the headings (trustworthy, objective, etc.) are visible to VoiceOver on OS X, there's no way to assign a rating to any of them that I can find. --Codeman38 (talk) 03:07, 11 January 2013 (UTC)
- Yes, it's not very accessible. But that doesn't matter so much, because it will soon be replaced by version 5 of the tool, which has its own accessibility issues but is more accessible than version 4. Graham87 06:02, 11 January 2013 (UTC)
- Yes. The problem is WMF developers never check for accessibility issues when producing features. They just don't have this necessary step included in their workflow. I'm wondering how to deal with this. Currently, there are not many cases of this happening. But as the developers are making an increasing number of tools and other changes it might become a nightmare. Dodoïste (talk) 08:32, 11 January 2013 (UTC)
- Actually the developers do consider it. It's not a distinct element of the workflow in terms of "we spend features requirements time working out precisely what will/could wrong", but trying to make things accessible is a pretty accepted part of development (I'd argue that "there are not many cases of this happening" is possibly evidence not of negligence but of competence). Okeyes (WMF) (talk) 14:43, 11 January 2013 (UTC)
- Yes, this is also what I intended to say. My apologies, I should have included more details in my previous comment. We have interacted with several developers so far, and many seems interested and compelled to produce accessible software. We do notice that common accessibility requirements that most developers are aware of are taken into account spontaneously. This should be praised as an effort from the developers. They care. :-)
- What I intended to say, is that they can only do so much without expertise. In the current development process, it shows that there are no formal verification using a rigorous methodology. Such a methodology would be 1) using the WCAG check-list or associated tools, or 2) asking for independent review or 3) hiring an accessibility specialist to work with the developers. I would encourage the third, as an internal specialist would allow for a fluid and easy development process. It would also improve the skills of the WMF developers regarding accessibility. Thanks for reading this, Okeyes. I hope it helps. Dodoïste (talk) 15:11, 11 January 2013 (UTC)
- It does :). Obviously I don't have the authority to hire anyone (alas, alack. If I did, I'd be retired in Mali with four people doing my job in SF ;p) so I can't help directly on No. 3. I think the closest we have to an accessibility specialist, for AFT5 at least, is Graham :). He's always wonderfully helpful. I'm actually setting up a meeting with the head of features engineering anyway - I'll see if I can work the WCAG checklist in. Okeyes (WMF) (talk) 15:53, 11 January 2013 (UTC)
- That would be a good step; but a better one would be to ensure that every new feature is tested by a variety of people with special access needs; including., for example, people like Graham, who use screen readers, but also people who have limited sight and so require very large text, and people with dexterity limitations who cannot sue a conventional mouse. That might mean volunteer Wikimedians; or outsourcing to a specialist testing company who have such people on their books. We ought to add accessibility to the 5 pillars; perhaps adding under the third ("Misplaced Pages is free content that anyone can read, edit, use, modify, and distribute"); possibly as a new, 6th, item, with gender and other equality matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 11 January 2013 (UTC)
- Nah, Andy. For several reasons, it is not very efficient to test each new feature with a variety of users. And it can't be included smoothly in the development process. In most cases it is sufficient to conform to a check-list, because the needs and the solutions are standardised. However, for special and complex cases like building a visual editor it would be necessary to test with a blind user.
- @Okeyes: Thanks for creating this opportunity. If you favor the WCAG check-list solution, I heavily recommend the use of the summarized and simplified check-list made by WebAim experts (PDF version). Developers often perceive WCAG as an overwhelming mountain of guidelines that only accessibility experts are able to use. Rightfully so. Webaim summarized it all in a 6 page document that is easy to read. It is meant to be a cheatsheet to use when in doubt. It is best that developers receive a 1 day introduction to WCAG methodology before using such a check-list. There are many accessibility experts who provide accessibility training anywhere it the U.S. You should be able to find one in San Francisco. Cheers, Dodoïste (talk) 00:37, 12 January 2013 (UTC)
- Sweet! I'm not based in SF myself, but I'll see what progress I can get/what checks they do now :). Okeyes (WMF) (talk) 16:13, 17 January 2013 (UTC)
- That would be a good step; but a better one would be to ensure that every new feature is tested by a variety of people with special access needs; including., for example, people like Graham, who use screen readers, but also people who have limited sight and so require very large text, and people with dexterity limitations who cannot sue a conventional mouse. That might mean volunteer Wikimedians; or outsourcing to a specialist testing company who have such people on their books. We ought to add accessibility to the 5 pillars; perhaps adding under the third ("Misplaced Pages is free content that anyone can read, edit, use, modify, and distribute"); possibly as a new, 6th, item, with gender and other equality matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 11 January 2013 (UTC)
- It does :). Obviously I don't have the authority to hire anyone (alas, alack. If I did, I'd be retired in Mali with four people doing my job in SF ;p) so I can't help directly on No. 3. I think the closest we have to an accessibility specialist, for AFT5 at least, is Graham :). He's always wonderfully helpful. I'm actually setting up a meeting with the head of features engineering anyway - I'll see if I can work the WCAG checklist in. Okeyes (WMF) (talk) 15:53, 11 January 2013 (UTC)
- Actually the developers do consider it. It's not a distinct element of the workflow in terms of "we spend features requirements time working out precisely what will/could wrong", but trying to make things accessible is a pretty accepted part of development (I'd argue that "there are not many cases of this happening" is possibly evidence not of negligence but of competence). Okeyes (WMF) (talk) 14:43, 11 January 2013 (UTC)
- Yes. The problem is WMF developers never check for accessibility issues when producing features. They just don't have this necessary step included in their workflow. I'm wondering how to deal with this. Currently, there are not many cases of this happening. But as the developers are making an increasing number of tools and other changes it might become a nightmare. Dodoïste (talk) 08:32, 11 January 2013 (UTC)
Accessibility and equality as core policies
Further to the above: I propose that we add a commitment to accessibility and equality to the Five pillars. Please join discussion at Misplaced Pages talk:Five pillars#Accessibility and equality. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 11 January 2013 (UTC)
Template:Track listing
I'm sure this question has been asked of every template under the sun, but I'm far from proficient in judging these things. A recent peer review threw up the question of whether Template:Track listing (more specifically, its use in Laborintus II, which is a standard example) meets MOS:ACCESS/MOS:DTT. The template itself nests a few other templates which makes it a little tricky for me to wrap my head around what I'm meant to be looking for. From what I can make out, though, it does seem to meet MOS:DTT by giving the appropriate scope qualities for its rows and columns, but to be honest I don't know what to look for after that. If anyone happens to know off-hand that would be great, or even if there is a decent free screen-reader I could be pointed towards to test how it turns out, that would also be fantastic. Thanks in advance to anyone able to help with this one. GRAPPLE X 23:55, 6 February 2013 (UTC)
- The Template:Track listing was made fairly accessible on march 2012. Most of its inclusions should meet MOS:DTT, as far as I can tell. Its use in Laborintus II is standard thus accessible.
- This template could still be improved in theory, but the benefits would not be obvious in regards to the costs. Thus "track listing" is good enough as it is now. Thanks for your concern, Dodoïste (talk) 17:12, 8 February 2013 (UTC)
- Happy days, thanks very much for the response. GRAPPLE X 23:47, 8 February 2013 (UTC)
The change I have suggested at Template talk:Track listing#Album_name + artist is still needed, both to improve accessibility, and to make it possible for the template to emit useful metadata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:24, 20 February 2013 (UTC)
Election candidate table rows
Please review the accessibility of the table rows in, for example, Pennsylvania Senate elections, 2008. They use {{Election box inline incumbent}}, {{Election box inline candidate with party link no change}} etc. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:00, 20 February 2013 (UTC)
- Nice catch. This table has significant issues, ones that are very common in this type of articles. Good news are the templates should allow for easy and massive improvements. Will try to look into this today, if I can. Cheers, Dodoïste (talk) 09:27, 23 February 2013 (UTC)
- If found a potential solution, what do you think of this cell border-left color proposal? Cheers, Dodoïste (talk) 13:48, 23 February 2013 (UTC)
Alt attribute review
What's the best text to use in the alt attribute of the image on Northampton Museum and Art Gallery? Please comment on that article's talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:05, 20 February 2013 (UTC)
Color contrast ratio template
There is a new Wiki template for calculating the W3C recco'd contrast ratio of a color pair, described at Misplaced Pages:Lua requests § Check if a pair of colors has enough contrast for acessbiility. —— 18:10, 1 March 2013 (UTC)
- Thank you again for creating this template! Helder 19:40, 1 March 2013 (UTC)
Categorization of pages with contrast problems
Hi!
What do you think of using the (new) {{Color contrast ratio}} to check if the two colors provided to {{Font color}} have an appropriated contrast, and if not put the page in some maintenance category, maybe a subcat of Category:Articles with accessibility problems? Helder 19:40, 1 March 2013 (UTC)
- I can see this being very useful. for templates that explicitly ask for the fg and bg colour, we could certainly add this as a way to track situations with poor contrast. for other situations, like navboxes, we would need a way to extract the background and foreground colour from the style statement. I suppose this is also possible using string matching? also, is there a way to get this to work for named colours, like "white", "green", "black"? you would need a table with the list of html colours. currently these resolve as an error message. Frietjes (talk) 22:42, 1 March 2013 (UTC)
Done The 16 HTML colors and CSS "orange" are now supported (case-insensitive). —— 00:26, 2 March 2013 (UTC)
- Both Chrome and Firefox are able to "Inspect element" from a right-click menu which will give you the color/background-color values of any text with a little scanning. The only point I'd make is that WCAG AAA standards demand a ratio >7 (or <0.143) for normal sized-text (4.5/0.22 only meets the AA standard for normal text), and I'd rather we aimed for AAA-compliance where possible. I've yet to see a good reason put forward why our articles should have any difficulty in reaching the higher standard in these cases. --RexxS (talk) 00:15, 2 March 2013 (UTC)
- Sure, but if we can reach AA level consistently it will already be a great achievement. AAA where possible, but we can't achieve AAA level consistently. You know how Wikipedians love to be consistent, don't you? I believe aiming at AAA level is risky as it could lead to unnecessary disputes. Dodoïste (talk) 09:24, 2 March 2013 (UTC)
This is one of the areas where it's not so difficult to reach AAA level if editors are aware of what is needed, and therefore we should be raising awareness as much as possible. Let me give you a real example. In the article Alpha Centauri there is a table with this header:
| Companion (in order from star) |
Mass | Semimajor axis (AU) |
Orbital period (days) |
Eccentricity | Radius |
|---|
With monobook skin, the contrast ratio between the hyperlinked text (#002BB8) and its background (#A0B0FF) is 4.980568493291 (note: we don't need that much precision) which meets AA and fails AAA. But if the background colour is changed to #CAD4FF the table header becomes:
| Companion (in order from star) |
Mass | Semimajor axis (AU) |
Orbital period (days) |
Eccentricity | Radius |
|---|
which yields a contrast ratio of 7.0534335018797, meeting AAA and clearly more legible to me, although it has the same hue. Now can anybody supply a sensible reason why the latter is in any way inferior to the former? If the designers of the template that produces the header were aware of the WCAG AAA level requirements before they started, then I have little doubt that they would have chosen a higher contrast in the first place.
I agree there are many areas where achieving AAA would require far more effort than can mustered at present, but this isn't one of them. I'd suggest that the documentation for {{Color contrast ratio}} might mention the ratio of 7.0:1 as the WCAG AAA standard, which would hopefully encourage clueful editors to adopt that as part of their design. --RexxS (talk) 14:44, 2 March 2013 (UTC)
- The template documentation was improved a little to show which color combinations are desirable. Helder 13:46, 29 March 2013 (UTC)
RFC: templates for specific accessibility problems?
Anyone thinks it's worth adding templates for specific self-explanatory accessibility problems? Example: Blind user notices image in entry without alt= (or other as appropriate) description, flags it. Unless what should go in the description is unclear to sighted editors familiar with entry topic, there should be no need for additional talk page discussion. — Preceding unsigned comment added by PauAmma (talk • contribs) 21:54, 17 March 2013 (UTC)
- Responding to the specific example: wouldn't that be a bit of an eyesore, considering that almost all images lack alt text? See a relevant conversation on my talk page. I could just imagine that template causing lots of wiki-drama, because there'd be no way to restrict use of that template to blind people; I'm sure *somebody* would go around trying to add it everywhere. Another problem with templates like that would be advertising them to the right people. Most readers don't edit, and most new editors would have no idea how to use templates. Graham87 01:45, 18 March 2013 (UTC)
- Fair enough wrt the specific example and the advertising/educating hurdles you mention. I still think a quick way to flag specific problems may be useful even then, although I'm not sure what form it should take considering what you said. Any idea? The Crab Who Played With The Sea (talk) 18:51, 14 April 2013 (UTC)
- Probably a template that has no visible output, but adds the page to a (hidden?) category like Category:Unclassified articles missing image alternative text. Browsing that category would keep the WikiGnomes in work well into the next decade.
- Addendum: Template:Alternative text missing already exists and does the job I suggested. --RexxS (talk) 19:41, 14 April 2013 (UTC)
- Works for me, thanks. The Crab Who Played With The Sea (talk) 19:53, 14 April 2013 (UTC)
- Fair enough wrt the specific example and the advertising/educating hurdles you mention. I still think a quick way to flag specific problems may be useful even then, although I'm not sure what form it should take considering what you said. Any idea? The Crab Who Played With The Sea (talk) 18:51, 14 April 2013 (UTC)
RFC: cleaning up and expanding the list of userbox disability templates
Template:User aspie redirects to Template:User Asperger: is there a reason to keep it on the list?
Also, which templates are missing from the list? (Existing ones or ones to be created.) Off the top of my head, I can think of depression, diabetes (all types), motor disabilities (all types/variants, including congenital/acquired/progressive if relevant), pain-related conditions, and acquired/progressive mental disabilities like Alzheimer's, but there are certainly others that should be included. — Preceding unsigned comment added by PauAmma (talk • contribs) 14:40, 31 March 2013 (UTC)
Make accessibility love, not edit war
Guys, can you please step back and take a break? I'm sure there's enough accessibility problems on Misplaced Pages that wasting time edit-warring about below vs. hereafter vs. whatever shouldn't be a priority. The Crab Who Played With The Sea (talk) 18:21, 14 April 2013 (UTC)
- Indeed, although I can see that we ought to be setting the best possible example where we can on these pages. I actually thought that Nnemo's latest attempt, "... to the following list", was far better than either "below" or "hereafter", but I'm not going to war over it. --RexxS (talk) 19:27, 14 April 2013 (UTC)
- Thank you, RexxS. “To the following list” is clearer than the other tries that were there before. --Nnemo (talk) 20:04, 14 April 2013 (UTC)
The beginning of this discussion is on my talk page. --Nnemo (talk) 20:06, 14 April 2013 (UTC)
Accessibility of new notifications system
I have raised a concern about the accessibility of the new Notifications feature]] for screen readers. It'd be best to make any substantial comments about it in the relevant bug report. Graham87 13:16, 4 May 2013 (UTC)
Coloured links and █ characters
At Misplaced Pages talk:WikiProject Trains#Additional comments (and the end of the immediately preceding section) there is a discussion about the accessibility of text and links in the colours of lines used on rail system maps, and about using things like coloured table cells and coloured block characters like █ as alternatives, especially how screen readers deal with such things. Please could someone with knowledge of this comment in that discussion, thanks. Thryduulf (talk) 12:22, 5 May 2013 (UTC)
HTML emails
There is a proposal to make Misplaced Pages's notification emails use HTML, with no user option to prevent that. Please comment at Misplaced Pages talk:Notifications#HTML email. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 16 May 2013 (UTC)
width:5px;font-size:1%;
How accessible is bodystyle=width:5px;font-size:1%; on an infobox? See, for example, St Mary's, Bryanston Square. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:50, 28 May 2013 (UTC)
- Why does it need to be that small? Is Nikkimaria trying to create a white dwarf? --Redrose64 (talk) 18:36, 28 May 2013 (UTC)
- I changed it to a collapsed infobox, which I know Andy doesn't like either, but will see how long that lasts. Frietjes (talk) 21:12, 28 May 2013 (UTC)
- I don't think anyone who understands accessibility likes collapsed content.
- Collapsing was a compromise solution to deal with articles that had a multitude of (or bulky) navboxes. Collapsing should never have escaped from its use in navboxes. It's being used in infoboxes for entirely the wrong reasons - akin to the perennial suggestion that we put "spoilers" in a collapsed section. (I did find the long long discussion at TfD after it had closed, but I do not wish to rehash it here/now).
- Yes, font-size:1% it utterly inaccessible, and I will assume it was a bad joke. There are lots of those around this topic. Let's try not to bludgeon the carcass of this one. –Quiddity (talk) 23:19, 28 May 2013 (UTC)
- I changed it to a collapsed infobox, which I know Andy doesn't like either, but will see how long that lasts. Frietjes (talk) 21:12, 28 May 2013 (UTC)
RFC at WT:ACCESS
There is a discussion at Misplaced Pages talk:Manual of Style/Accessibility#RfC: What is the scope of this guideline? about whether accessibility should be encouraged for talk pages, project pages, etc., or just for articles. WhatamIdoing (talk) 23:31, 6 June 2013 (UTC)
VisualEditor is coming
The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.
A couple thousand editors have tried out the early test versions so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that WP:Flow is ultimately supposed to deal with talk pages).
The developers are asking editors like you to join the alpha testing for the VisualEditor. This is especially important for people who deal with accessibility, because it always takes a while to write, test, and deploy code—so it's important to get any major problems on the list sooner rather than later. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Misplaced Pages:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.
Also, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new. The WMF is committed to this long-requested improvement, and it's my impression that nothing short of a complete collapse of the servers will cause it to be reversed, so we need information that will help them get it right. The new editing system will become the default, not the only option.
If you have any other questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. Thanks, WhatamIdoing (talk) 01:03, 7 June 2013 (UTC)
Category: