Monthly Archives: February 2013

esmi 12:05 pm on February 14, 2013
Tags: , , ,   

IRC Meeting Summary: 13 Feb 2013

As per last week, we had a very lively and interesting meeting with the main focus being Custom Menus (again) and the use of hidden skip links. Thanks to all who took part — especially a couple of UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. team members. The inter-team discussion is invaluable as it allows us to get a better perspective on the overall coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development philosophies as well as the current development cycle goals. I think the more we learn about the development process, the more effective we can become at offering practical, effective, suggestions at the right times.

User Testing

@accessiblejoe will be looking at developing videod user tests for the CSUN conference based on the list provided by @GrahamArmfield and the alter discussion on IRC:

  • Logon and interpret dashboard and toolbar
  • Publish new post including use of headings, bold etc. Add categories and tags.
  • Edit post to add media (image or pdf) with caption, alt text etc.
  • Update user options including setting new password
  • Use Theme CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. to change Site Title and background colours etc.
  • Creation of a simple custom menu; re-ordering of menu items including a single item sub-menu.
  • Logging out of WordPress.

We hope that any videos obtained will help the core development teams to gain a better understanding of some of the issues faced by disabled users.

Front-end AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)

@joedolson is still working on an extension of the Theme Check pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party as part of the optional accessibility audit for all themes submitted to wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/. He now has a modified version of the plugin available for testing and is actively looking for feedback.

There was also a lively discussion of “hidden” links — including both skip links and the current log out link (which is effectively hidden in a dropdown) — and balancing link visibility with the need to avoid a cluttered interface.

Finally, a reminder to all readers that, as a group, we are still stretched pretty thin and would welcome new members — both technical developers and non-technical disabled authors.

#wordpress-ui log for February 13 2013

#core-2, #irc, #meetup, #testing

Joe Dolson 11:12 pm on February 13, 2013
Tags: reviews,   

Progress Report: Theme Review Guidelines for Accessibility

Per the most recent conversations about the accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)-ready tag for the theme repository, I’ve been working on establishing some new classes for the Theme Check plug-in that can scan themes for accessibility issues.

Because accessibility is not easily verified, particularly when you’re not working in an HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. context, most of these are relatively generalized, and work on the principle that I want to avoid false positives (accessibility issues detected that don’t actually exist), but am perfectly comfortable with false negatives. The reason for this is that these are only intended to be indicative flags; they aren’t intended to substitute for an actual reviewer going over the themes and judging it according to the theme accessibility audit guidelines.

The idea is that any definite failures we can identify before engaging in a hands-on review are beneficial — and because theme authors have access to the Theme Check plug-in and can scan for these issues themselves, and learn of them before they submit.

I’ve prepared six classes to extend the Theme Check plug-in, but they could all stand a review (and some creativity in reviewing other areas, if you’re comfortable enough with PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php.).

You can download my modified version of the Theme Check plug-in (six new files, one edited: new files in /checks/, prefixed with a11y; edited file is just the stylesheet, to add a color for the class .tc-accessibility.)

Experiment with it, change it, let me know.

Some of these are very superficial or crude checks; but if you have an idea how to improve them, share your wisdom! Keep in mind that all of these tests are performed on un-rendered code; so using a DOM parsing engine is not an option — we can use standard testing methods when it comes to reviewing the ultimate output of the theme.

Accesskeys

Any use of accesskey is a failure, so this class returns an error if any occurrence of the string ‘accesskey’ occurs anywhere in any theme PHP file.

Form labeling

Examines each PHP file individually. If any file contains input, textarea or select elements without also containing a label element, returns an error. This is superficial, as it doesn’t currently verify that there is any equivalency between inputs and labels, and doesn’t specifically exclude hidden inputs as an acceptable case.

Image alt

Examines each PHP file individually. If any file contains the string ‘<img’ but does not contain the string ‘alt=’ it returns an error. It’s crude, and this could definitely be improved.

Empty links

Examines each PHP file individually. Runs a regex to identify link text, returns errors for any link with no content. However, the actually cases within a theme are so diverse that there are *many* circumstances that this won’t pick up using the current rules, including link texts consisting only of white space characters, linked images with no alt attributes, or complex PHP concatenations.

Tabindex

Just like the accesskey check. However, there are allowable cases for use of tabindex, and this class does not account for those at the moment.

Headings

Scans the PHP files for occurrences of the strings ‘<h1’ and ‘<h2’. All it’s verifying is the presence of structural headings. If no structural headings are found anywhere in the code, it returns an error indicating a lack of HTML heading structure. Also very crude, but it will pick up the worst-case scenario.

#reviews, #theme

Graham Armfield 5:08 pm on February 13, 2013
Tags: , , ,   

WordPress Accessibility Trac Tickets Update – 13 Feb 2013

This is a useful link that returns all the accessibility-related trac tickets.

Existing TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. Tickets (Bugs) that aren’t Fixed.

12825 – Text resizing in Firefox – Raised 3 years ago(!) this one talks about the fact that WP admin screens don’t always look very clever when text is resized by user. Whilst most areas are OK, the buttons and toolbar at the top of the page are fixed-height and so text-spillage occurs. I don’t think everyone realises that zooming and resizing text are not the same thing and suit different people.

20294 – User password field missing label – Looks like some work was done for 3.5 but it appears it was never implemented.

21289 – Custom Menu builder – Raised last year but turned out to be duplicate of 14045 and linked to 22485. Ticket 23119 (see also below) is covering the rework of Custom Menus and design is still being debated hotly. Need to keep eye on this one as Custom Menu Builder has never been accessible since first introduced.

21334 – AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) of Quick Edit Panel – Raised last summer, and is getting some attention now. Have suggested (amongst other things) that quick edit panel might be always visible as a result of switch in Screen Options, but kind of nervous about that. Could do with some further accessibility input (ie not just mine). The issue about whether certain links should be permanently visible coming in here as well – cf Skip links at top of page.

22104 – High contrast admin colour scheme – Raised in the autumn, and some debate ensued. However nothing really happened about this. Do we want to get behind this? Is there one high-vis theme that would work for all?

22606 – Keyboard issues selecting a background image in Theme CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. – Seems there is a fix for this, but need to test.

22682 – More keyboard issues with Theme Customizer after page refresh – Some action but has been downgraded in importance just before Christmas.

22933 and 23195 – Keyboard tab order in edit screens – Fix is now available that makes tabbing more consistent allegedly. But I haven’t been able to test this.

Trac tickets covering UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. work

23119 – UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. improvements to nav-menus.php – A LONG ticket with much debate. Difficult to work out exactly what is being proposed for accessibility here. One ticket proposed that accessibility option like widgets should be included – and apparently the stubs for that code are actually in the menu builder and may be used if js not available. Cyndy pointed out within ticket that drag and drop, and even using arrow keys to move items is not really any good for blind people. But would that be an option if there was sufficient announcing (using ARIA live regions?) to allow context to be voiced? And is it OK to just use the arrow keys for this – when users might expect something different to happen? And what about users on tablets using AT like VoiceOver?

New tickets required?

Add Media Functionality – don’t believe this is keyboard accessible (inc screen readers), nor easily accessible by speech recognition software either. But haven’t had chance to test yet.

#core-2, #development, #media-manager, #menus

esmi 3:07 pm on February 12, 2013
Tags: , ,   

IRC Meeting Agenda: 13/02/13

Is there anything we need for tomorrow’s meeting agenda?

Or should we just make this a “report & update” meeting?

#group, #irc, #meetup

esmi 11:30 am on February 8, 2013
Tags:   

Post Revisions in 3.6

The Post Revisions are currently being overhauled for WordPress 3.6. The team responsible are at the concept stage & they’ve asked asked us to provide feedback now on their current mock-ups.

I have already raised the point elsewhere that perhaps a red/green combination isn’t the best of choices but I do think that the potential barriers here could be greatly mitigated if one of the mock-ups with strike-through (currently the favoured approach) was chosen. The screenshot below shows how these screens might be viewed by someone with the most common forum of colour blindness (protanopia).

Full size mockup of protanopia view

Seems to me that the markup used could also greatly enhance accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) here — with proper use of both the <ins> and <del> HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. tags.

Any other thoughts?

#revisions

esmi 1:10 pm on February 7, 2013
Tags: , , , ,   

IRC Meeting: 6 Feb 2013

Thanks to everyone who managed to make the IRC meeting on #wordpress-ui yesterday.  We had a very productive discussion and — despite the entertainment provided by way of my terrible iPad typing — took the first steps towards organising the group along more formal lines.

@GrahamArmfield will be looking after TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/.. Time permitting, he will be monitoring the existing accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility)-tagged tickets and taking the lead on the submission of new Trac tickets to cover issues such as the problems within the current custom menus admin area. So if you are thinking of raising a new Trac ticket, can you raise the subject here first? That way, we should avoid unnecessary replication.

@joedolson expressed a vested interest in the editorial flow area but, for the time being, will be concentrating on front-end accessibility via the proposed theme accessibility audit and an extension to the current theme submission checks.

@AccessibleJoe will take the lead on user testing videos so that we can build up a library of video resources to support coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. developers.

@esmi will continue to take lead on documentation (liaising with @Siobhan and @DrewAPicture) as well as working with @lessbloat and other members of the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. team to try to develop in-house user accessibility testing.

We are, however, still stretched pretty thin. So if you would like to get involved, we would love to hear from you. Those of you with the skills to create patches will be particularly welcomed by the UI Team who are currently overhauling the Custom Menus and Post Revision areas.

#wordpress-ui log for February 6 2013

#group, #irc, #meetup, #testing, #video

esmi 4:02 pm on February 6, 2013
Tags: ,   

IRC: Proposed Schedule

Venue: #wordpress-ui
Server: irc.freenode.net or via freenode web chat.
Time: Wednesdays, 20:00 UTC

Meetings should take no more than 1 hour — possibly less. If anyone is available today, I should be around at that time.
First official meeting will be February 13.

First orders of business:

  1. Define this group’s role in the overall development of WordPress
  2. Look at intra-group organisation as a possible way to circumvent that “totally overwhelmed” feeling.
  3. Discuss the development of semi-formalised, pan-disability, user testing

#irc, #meetup

Graham Armfield 12:28 pm on February 6, 2013
Tags: , post formats,   

Are Trac Tickets Still the Best Way to get Accessibility Improvements in WordPress?

Last year, as a result of a number of tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets raised by myself and others, a number of accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements were made to the WP admin screens in 3.5. This was a good thing in that it showed that some WP developers were happy to address the challenges with existing functionality. And for existing accessibility issues I suppose this is still the right vehicle.

However, I’m troubled with this approach when I think about new functionality that is being developed within every release of WordPress. So far in 3.6 I’m seeing that there are going to be significant changes to the UIs for Custom Menus, Post Formats, and Post RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. – and there may be others.

It feels to me that there is a disconnect here. All these new and ‘improved’ features seem to get hammered out and developed without accessibility really being thought about. Using trac tickets here to raise accessibility issues seems like trying to bolt the stable door after the horse has departed.

I think it would be a disaster if these new features are developed without some consideration for accessibility, and I’m sure we can all agree that it’s a lot more work to retrofit accessibility into developments. In fact sometimes it’s not really possible – when the design is so alien to accessibility.

I’d hate to see Custom Menus, Post Formats, Post Revisions become the next accessibility disasters – like Theme CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings., and the new Add Media Panel.

Is there anything we can do to ensure that this doesn’t happen?

#menus, #post-formats, #revisions