Talk:Accessibility guide for developers

Notes from Dodoïste
Hi there, good work on summarizing things for developers. A developers knows best what a fellow needs to works efficiently, so I'll leave the summarizing to you.

There is advice I would like to add about keyboard navigation. I'll write the full explanation here, and let you shorten it as needed. Cheers, Dodoïste (talk) 23:59, 31 July 2012 (UTC)

Keyboard navigation
Ensure that every interaction can be used by both the keyboard and the mouse. This is especially relevant for JavaScript and AJAX events. To test keyboard navigation, use the TAB key to access the interaction, and ENTER to use it.

Mouse event handlers should be accompanied by redundant keyboard event handlers. Only "Onclick" is universal.

TABINDEX should not be used, as it is difficult to use correctly and is annoying to update. The tabulation order should be natural, following the order in the HTML. The search box might be an exception where we want a TABINDEX set to 1.

Note: This issue is found in the Vector skin left navigation menu. TABINDEX is not used correctly: interaction menus come first, and the links they contain are a the bottom of the page.

References:
 * G90: Providing keyboard-triggered event handlers
 * SCR2: Using redundant keyboard and mouse event handlers
 * SCR35: Making actions keyboard accessible by using the onclick event of anchors and buttons
 * SCR20: Using both keyboard and other device-specific functions

Screenreader notes
I linked to 3 youtube videos at w:Wikipedia talk:Manual of Style/Accessibility/Archive_13, that you might find useful, and I hope we can find more.

The other software that seems to be recommended the most often, along with the commercial/demo of JAWS, and the Fangs demonstrator, are the open source NonVisual Desktop Access (NVDA) (windows) and Orca (assistive technology) (*nix). I've briefly tested out Fangs and Orca, and recommend them both.

HTH. Quiddity (talk) 16:55, 12 August 2013 (UTC)

Visually impaired editors
w:Wikipedia talk:WikiProject Accessibility/Archive 4 - A thread with useful feedback from editors, mainly concerning screen magnifiers, and other software tools. –Quiddity (talk) 01:13, 8 October 2013 (UTC)

Keydown handler for space
Why should space (keyCode 32) handled for keyboard navigation? Normally the space makes a scroll down. --Fomafix (talk) 15:39, 29 June 2014 (UTC)
 * I think that is just Mac OS X actually. But if you look around a bit you can find multiple sources with this advise: To list a few    . TheDJ (talk) 18:03, 29 June 2014 (UTC)
 * It's specific to forms - the spacebar is used for toggling things (like checking a checkbox or activating a button) if you tab to them. You can try it when tabbing into the checkboxes in the editing interface; it should be consistent across browsers. -— Isarra ༆ 05:20, 30 June 2014 (UTC)
 * I always use spacebar for that on MediaWiki with Firefox and I've never had any issue. --Nemo 14:30, 1 July 2014 (UTC)
 * You won't have an issue using native browser forms (which mw currently uses for most functions) - the point there, I think, is that developers need to not cause issues when writing their own forms or overriding native form functionality with js. Need to make sure they either add the navigability functions back, or include them in their own implementations, depending on what they did. -— Isarra ༆ 18:33, 1 July 2014 (UTC)

Linkdump - accessibility and usability
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:26, 27 July 2014 (UTC)

Request for accessibility specifications

 * en:Wikipedia:Village_pump_(WMF)

I made a request to the Wikimedia Foundation at English Wikipedia.  Blue Rasberry   (talk)   20:37, 8 September 2020 (UTC)

Proposal for restructuring and amending the page
Hi, a group of Wikimedia Foundation employees, among them Bernard Wang and myself, Volker E., are proposing to update the following article:

Overall we'd reframe the article on high level goals for what accessibility is meant for in Wikimedia context, probably orienting on the WCAG's POUR principles. Also defining clearer the audience and making sure that folks know what types of impairment are handled in the article.

In the technical section we'd opt for starting with the biggest, most impactful mistakes to avoid. Inspired by the WebAIM Million report's detected errors.

Given the in-parts already historic character of the document, we'd also suggest to remove outdated and very low impactful detailed instructions and rather link out to best-practice documentation instead. Examples would be the “avoid” section, that could be avoided nowadays (excuse the pun), or examples like `title` attr for links.

By keeping the examples high-level the focus is better directed.

Volker E. (WMF) (talk) 19:02, 17 March 2023 (UTC)


 * This sounds really good.
 * The only thing I'd hesitantly suggest is: keeping in mind (and perhaps also using as part of the page-structure itself?) the various different audiences for this info. I.e. Not just core+extension developers, but also developers of site.js/gadgets/userscripts/modules/tools/(etc?). Quiddity (WMF) (talk) 20:31, 17 March 2023 (UTC)