Core Dev Team Meetup Q&A

It would be nice to see some movement in 3.4 on improving child theme inheritance (like johnbillion’s concept outlined in #18302). This could really expand the breadth and capability of child themes.

1. Since a certain level of emphasis has been placed on Post Formats, what plans does the Core team have to improve on and further promote more widespread adoption? From a UI/UX standpoint, taking a gander at what Alex King and CF’s been up to with their Post Formats UI plugin might be worthwhile.
2. There’s been some talk in IRC and on the Trac about breaking the admin theme(s) out of the Dashboard into a plugin, which would also open the door to a accessibility-friendly high-contrast theme. Is this functionality something that might make it into the 3.4 scope?
3. Alluding to Justin’s question and Ipstenu’s recent series about sidebar/widget management in a Menu UI environment, what are your thoughts about adopting that approach?
4. Can you give us any hints on future plans for www.remarpro.com?

1. What will be done to address the issue of slower response in WordPress 3.3 compared to other WordPress versions? (Currently the new WordPress 3.3 is noticeably slower).
2. Given the forward momentum of web technology and interface design, why was “Responsive Design” not used for the admin interface? Note: The features say it is. However on Android, I don’t see that?
3. Given the increase in mobile access, why was the left sidebar navigation in the administrative area changed, so that it is even less mobile friendly than it was?
4. What steps are being taken to avoid bloat in the WordPress admin GUI and it’s code? I see the most recent version going this way, which leaves me concerned.
5. Is there a simple way to revert the media upload “drag and drop”, back to the way it was in WordPress 3.2.1, yet still retain 3.3.x core? Almost every single user I’ve talked to, have indicated they prefer the previous UI (which kind of blind-sided me as I thought it was okay)
6. Again, the biggest issue is the performance hit the new version (3.3) incurs. What is being done to address this?
7. Would the dev team consider a modular approach? What I mean by this is the ability for WordPress installations to select only the specific features required. This should help reduce loads – particularly when some features may never be used or required (so why have them installed?) Much in the same manner that plugins that are not required for some functionality are removed, or never installed.

Personally, I like the new version! GREAT JOB!!!! ?? And I appreciate you letting us ask questions.
Thanks!

Accessibility Requests – Part 1 – Front End:

1) Please can twentyten and twentyeleven be amended to enable flyout menus to be keyboard accessible. Without that, sub-pages on some sites might be impossible to get to for blind users and those who realy on keyboard interaction.

When I create my own themes I use the technique documented here: https://blakehaswell.com/lab/dropdown/deux/ – it’s simple and it works.

2) Please ensure in both those themes that the keyboard focus is always plainly visible – ideally the same as any hover changes.

3) Continue Reading links in blog page, search results, archives etc – should include page/post title to give the links the full context. This would help screen reader users who may get list of links on a page to help them navigate. If required the title part could be hidden from sighted users by using your ‘screen-reader-text’ class.

Some admin area thoughts shortly.

Accessibility Requests – Part 2 – Back End:

I expect everyone who is sighted and who uses a mouse is fine with the back end so my thoughts concern those who are blind (using screen readers), and those who are sighted but may use a keyboard (or a similar device) to navigate their way around web pages and apps. I have tried a few admin screens using just a keyboard and NVDA screen reader. I’ve listed the items in the order that I came across them – not order of importance.

1. A skip link to the main content at the top of the admin pages would be really useful since there are many links on every page before you get to the real business for each page. This link should either be visible all the time or become visible when it gets focus – as with twentyeleven theme. A link back up to the start of the main nav bar would be useful too – positioned near the end of content.
2. Keyboard focus must be clearly visible at all times.
3. All input fields should have explicitly linked labels which explain the purpose of the input. Examples of those that haven’t got label – a) Search pages text box b) The checkboxes on the table containing posts/pages etc. These labels could be hidden from sighted users.
4. Where you have radio buttons such as in the screen options panel the use of <fieldset> and <lefend> helps to set the context for screen reader users. <fieldset> and <lefend> would also be useful on the “Show on screen” options within screen options.
5. Screen options link reveals panel which is above current cursor on page. Blind users will therefore possibly not be aware of it. Some hidden text could warn screen reader users that they need to tab back up to see the options. Alternatively you could force focus into the first input within the panel.
6. In the Right Now section of the Dashboard the links to posts, pages etc are separate links from the number of each item. This leads to a series of meaningless numeric links for screen reader users. Can the number and the type of content not be combined into a single link?
7. In the Pages screen (with the big table of pages) the column titles activate a sort. For screen reader users’ benefit the link should state that.
8. Actually creating and editing a page is tricky using keyboard only and listening to NVDA:

• Once you’re into the rich text area the tab key no longer appears to work. So it’s not clear how to get out of the rich text editor. Using the help available at ALT+0 doesn’t actually help with that either.
• It’s not clear how I get to the controls to save as draft or publish the page.
• It’s not clear how I would access the upload media dialogue once in the rich text editor as that seems not to be part of the toolbar.

All the instructions that are provided for screen reader users need to be clearly visible somehow for sighted keyboard users – perhaps a plainly visible Accessibility Help link at the top of each page?

• Cheated and reloaded the page so I could access the media uploader. Managed to tab to it but when the link is actioned and the dialogue panel is opened the focus is not moved into the panel which I would expect. This would make it very hard for those using a keyboard to easily add media to their posts and pages.

I’ve run out of time now but I’ll try to do some more investigation next week.

Graham

As I mentioned in my post WordPress is not keeping up

start implementing what the community is actually using most to the core.

• are there plans on taking advantage of PHP 5.3 and increase page cache?
• have you thought about switching to mysql innodb using PK’s and relationships?
• Will you be implementing a database backup class or method
• Will you be further enhancing WordPress to clear out structured programming and make it fully class/object oriented?

That sums up what I would like to know – what I thought should have been included in the core a long time ago.