Jump to content

Talk:Accessibility guide for developers

Add topic
From mediawiki.org
Latest comment: 1 year ago by Quiddity (WMF) in topic Proposal for restructuring and amending the page

Notes from Dodoïste

[edit]

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)Reply

Keyboard navigation

[edit]

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.

Redundant even handlers
Mouse Keyboard
onmouseover onfocus
onmouseout onblur
mousedown keydown
mouseup keyup

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

[edit]

I linked to 3 youtube videos at w:Wikipedia talk:Manual of Style/Accessibility/Archive_13#Good videos demonstrating screenreaders in use, 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 w:NonVisual Desktop Access (NVDA) (windows) and w: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)Reply

Visually impaired editors

[edit]

w:Wikipedia talk:WikiProject Accessibility/Archive 4#Visual impairment - what settings, software, or other tools are used to compensate - A thread with useful feedback from editors, mainly concerning screen magnifiers, and other software tools. –Quiddity (talk) 01:13, 8 October 2013 (UTC)Reply

Keydown handler for space

[edit]

Why should space (keyCode 32) handled for keyboard navigation? Normally the space makes a scroll down. --Fomafix (talk) 15:39, 29 June 2014 (UTC)Reply

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 [1] [2] [3] [4] [5]. TheDJ (talk) 18:03, 29 June 2014 (UTC)Reply
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)Reply
I always use spacebar for that on MediaWiki with Firefox and I've never had any issue. --Nemo 14:30, 1 July 2014 (UTC)Reply
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)Reply

Linkdump - accessibility and usability

[edit]

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)Reply

Request for accessibility specifications

[edit]

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

Proposal for restructuring and amending the page

[edit]

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)Reply

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)Reply