Jump to content

Topic on Talk:Groups/Proposals/Accessibility Tracking

Some notes on the accessibilty tracking tables

2
Dantman (talkcontribs)

I have a few notes about some of the stuff in the tables.

1.3 - Problem B 1b: Listings and lists: CSS-class

Why does something this domain specific have to be tackled within MediaWiki? As long as the right elements are used in the pages instead of abusing something like tables all this takes is the css. I don't see anything that makes this something that can't simply be solved with the right css in the community.

We already had a bug on adding horizontal list css to core at bug 40062 and I've already explained the problems with i18n when you try to include this as part of the core software.

1.3 - Problem D 1: Semantically correct markup - layout tables:

This doesn't have to be a total no-no. At the very least layouts that are impossible to markup without tables should at least have role="presentation" set on them.

2.4.7 - Problem 2: Skip links

This should have already been fixed. Skip links aren't completely invisible to users. When you tab through the links the skip links are visible whenever focused.

The only problem with them is there seem to be tabindexes that make a bunch of other links like the sidebar headers and central notice messages show up before the skip links when they shouldn't. That and the css that central notice uses screws with the skip links making the notice overlap the skip links.

3.1.2 - Problem 1: Foreign-language parts – CSS class

We do have markup for declaring language, the standard lang="" and dir="" attributes. The only thing the new editor has to do is make it easier for users to add. VisualEditor will have to especially consider this. Since once you jump into WYSIWYG all metadata on language disappears completely from view.

Nemo bis (talkcontribs)

I think the general accessibility information here belongs to a specific page, either m:Accessibility or a successor for it.

Reply to "Some notes on the accessibilty tracking tables"