[wp-accessibility] Twenty Ten

Sun Sep 5 16:10:17 UTC 2010

Hi,

I'd be very interested in helping with admin accessibility, but does
it need to be a separate theme? Seems like a basic, accessible (even
mobile-friendly) admin area which is progressively enhanced would be a
better long-term goal.

Has any work started on this yet.

Chris

On 9/5/10, Jane Wells <jane at automattic.com> wrote:
>   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
>
> _______________________________________________
> wp-accessibility mailing list
> wp-accessibility at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-accessibility
>