[wp-accessibility] Twenty Ten

[Jane Wells]

  Hi Rich. It's great that you're taking initiative with this following 
the wpdevel discussion, but for anything that touches UI (link color, 
especially) it really needs to be coordinated with existing UI stuff. I 
have asked for volunteers before to do a separate admin theme that 
purely aimed at accessibility (much higher contrast, larger click 
targets, etc) but didn't get much response. We're going to be doing a 
CSS color sweep/cleanup in 3.1, so if you're changing link colors now, 
it's likely your patch will get overwritten without malicious intention.

Also, I know it seems silly, but each change should really be it's on 
patch. Better to have a patch of only a line or two that has a single 
function, so that if something has to be reverted, all the other changes 
don't get lost with it. Like in this example, if we needed to revert 
link color changes b/c they weren't approved UI changes, but we didn't 
want to lose newly-added labels or something, with it being one whole 
patch there would be an issue.

Also, if you were just going through and adding under-the-hood things 
for screen readers, etc., that would be fine to do independently, but it 
appears you are actually changing design things--colors, 
margins/padding, highlights--and these are not things that get changed 
lightly. The theme designer (since it is 2010 you're working on now) 
needs to be involved. Chances are he'd be fine with it, but actual 
changes to the UI need to run by him for design approval. I'll email him 
the ticket number you have listed below so he can weigh in and approve 
or identify any reasons he had for doing it the way he did. When you get 
to the admin, I would suggest working on an accessibility-specific admin 
color scheme first (which we would add to the existing blue and gray) 
rather than trying to patch the existing color schemes directly, as we 
can (and want to) approve a separate scheme fairly quickly, but changing 
the base UI for 20 million+ users is more political and takes longer.

If you intend to make changes that are visible in the UI, like adding 
elements on the screen and changing colors, you really should join the 
UI group and work through it there, so that your work doesn't get 
rejected as being out of alignment with the existing UI conventions. The 
UI group blog is at http://make.wordpress.org/ui and there are weekly 
IRC meetings on Tuesdays at 2:30pm in irc.freenode.net #wordpress-ui.

Thanks,
Jane

On 9/5/10 8:53 AM, Rich Pedley wrote:
> This list is unused, we need to start using it!
>
> Now I've made a start with looking at the accessibility of Twenty Ten, 
> starting with Links, well mainly.
>
> http://core.trac.wordpress.org/ticket/14782
> [quote]
>
> Starting off with changes to the CSS only.
>
> Links: colors amended where necessary. added underscores and/or color 
> changes for active, hover and focus.
>
> Gallery image links: adjusted things to use margin to center the image 
> rather than padding, to allow for adding highlighting on image links.
>
> Skip link: now appears above the #access menu when tabbing through the 
> page.
>
> Grey text/links: was 888 this just failed the color contrast, so 
> changed it to 777 throughout.
>
> Forms: added highlight for input text and textarea, for active and focus.
> [/quote]
>
> Feel free to add comments there.
>
>
> However I have an issue with the access (role: navigation) menu, which 
> can't be fixed with CSS alone, and is not just an accessibility issue, 
> but a usability issue.
> To test and replicate download and use the test data via
> http://codex.wordpress.org/Theme_Unit_Test
>
> You'll notice that the last link in the navigation is 'Parent Page', 
> hover over that, and then the 'Child page 1'. Unless you have a 
> widescreen the 'Child page 2' cannot be seen.
>
> Is there a javascript solution for this?
>
>
> Additionally of course because some of these pages are _only_ 
> accessible via the menu, there should be an alternative listing 
> display on the main pages linked. However that may be outside the 
> scope of what we can cover (other than _strongly_ suggesting a widget 
> is available that can do this).
>
> Rich
>
>
>
>
> _______________________________________________
> wp-accessibility mailing list
> wp-accessibility at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-accessibility