Tag Archives: menus

esmi 3:02 pm on March 14, 2013
Tags: , , menus,   

IRC Meeting: March 13, 2013

We had a little mix-up with the meeting time this week, due to the change to Daylight Savings Time in the US, so this meeting report may be a little shorter than usual.

However, the weekly meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. time remains at 20:00 UTC until the end of the month — when we may review and adjust it. Remember that you can convert UTC time to your local time at Worldtimeserver.com.

Continue reading →

#comment-form, #meetup, #menus, #trac-2

esmi 4:22 pm on March 7, 2013
Tags: , , , menus   

IRC Meeting: March 6, 2013

Another small but lively meeting. We also had the opportunity to welcome our newest member, @shaun_10up – a relatively new coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. contributor. I think we’ll be keeping him busy over the next few weeks! 🙂

Custom menus

Thanks to contributions from @lessbloat, @ceo and @quanin, we’re now seeing real, positive, progress on Trac ticket #14045. This greatly increases the chance of WordPress 3.6 being shipped with a more accessible custom menu system. Thank you for all of your hard work on this.

Continue reading →

#comment-form, #irc, #meetup, #menus

esmi 2:54 pm on February 28, 2013
Tags: , , menus,   

IRC Meeting: February 27 2013

As usual, we had a lively meeting. Thanks to all who attended.

Custom Menus

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) of custom menus in WordPress 3.6 and its related Trac ticket continued to be the main topic of conversation. This is undoubtedly going to be a very difficult area to get just right — not only in terms of the coding approach but also due to the problems of ensuring that screen reader users are presented with a meaningful construct when they try to manipulate menu items. Because of this, it was felt that there was a real danger of theoretical discussions taking priority over the development of prototypes. To try and avoid this, @GrahamArmfield and @lessbloat have agreed to take the lead together on developing prototype solutions.

Add Media Panel

@GrahamArmfield recently raised some concerns over accessibility issues within the current Add Media Panel and we decided to progress further with this. @ceo agreed to post a summation of the issues faced by some screen reader users shortly. Some possible new options were suggested such as an ability to tag images and filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. the library by tag or an option to filter the library by upload date. Both may offer some benefits to users trying to locate a specific file in a large library when they are unable to “see” the images in question.

Join Us

Finally, a reminder that we are still a relatively small group of active members (although we have 156 people subscribed to this blog by email). We do need more active members – both technical and non-technical. So do please consider joining the group.

#wordpress-ui log for February 27, 2013

#irc, #meetup, #menus, #twentythirteen

Cyndy Otty 2:25 pm on February 21, 2013
Tags: , , , menus, ,   

IRC Meeting Summary: 20 Feb. 2013

As evidenced by our small group at yesterday’s meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through https://www.meetup.com/. A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area., I want to first remind you all that we could very much use new members! Whether you are a developer and very technical or merely a writer with special needs, we would certainly welcome you to join us. Anyway, despite our numbers and lack of a formal agenda, our main discussion was on two topics that will be our primary focus presently.

Custom Menus

As the trac ticket concerning design changes to the Custom Menu has been closed, we discussed centering 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) discussion around the reopened trac ticket #14045. The proposal is for an accessibility mode screen alternative like that which the Widgets page utilizes. We also have a post devoted to this topic here as well for your consideration and comments.

Twenty Thirteen

Feedback is strongly requested from an accessibility standpoint on the new default theme Twenty Thirteen, which is currently being developed. You can check out the theme here at the Twenty Thirteen demo site and please report any feedback you have.

The full log of yesterday’s IRC meeting can be found here at #wordpress-ui logs for February 20, 2013.

#core-2, #irc, #meetup, #menus, #theme, #twentythirteen

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

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

Graham Armfield 12:28 pm on February 6, 2013
Tags: menus, 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