Core Dev Team Meetup Q&A (52 posts)

  1. esmi
    Forum Moderator
    Posted 4 years ago #

    how much is getting major attention from the decision makers for new releases?

    Unlike other aspects of development, accessibility isn't binary (black or white - right or wrong). http://make.wordpress.org/accessibility/ isn't simply for discussion. It's intended to allow those with the right skills to prioritise and refine accessibility issues so that these can then be presented to the core team as specific recommendations rather than vague requests.

    One tiny thing with a big impact would be to have the alt text field be mandatory

    Over my dead body! Are you serious? It is considered best practice to use a null alt text for decorative images - not a populated one. And there's no way that any UI can automate an alt description - or even decide if an image should have one or not. This is way outside the remit of an UI. It can only be addressed by educating users.

  2. dennissmolek
    Posted 4 years ago #

    When we talk about sharding a MySQL database people talk mostly about multisite. I am designing a site thats more of an application. I'm using Custom posts to handle most data objects because they share many of the same fields(name, created date, author, etc.)

    Currently I am looking at 1,000 posts being created a day with at least that many being modified. When we release and the plans of the company using the app I will hit 1,000,000 posts in less than a year.

    This is on a single post table, all with custom meta info. Talking to folks like JJJ makes me scared that it wont be sustainable. I have a auto scaling redundant hosting setup but a 1,000,000 record table seems like its going to slow things down.

    I know separate tables is devil talk in the core WP world and more of a PODS thing, but I can't just shard off parts like multisite folks.

    If we are really talking about using WordPress as a CMS beyond mom and pop stores, how do we address post tables of that size?

  3. Kirk Wight
    Theme Wrangler
    Posted 4 years ago #

    I would also love to see WordPress include native translation management; something implemented in the same way as Multi-Site for those of us who need it.

  4. Kurt Payne
    Posted 4 years ago #

    How do you see WordPress using its position as an industry leader to effect change in other areas?

    For example, WordPress' minimum server requirements and supported browsers will affect user behavior and have an economic impact on browser makers and hosting companies.

    Also, WordPress' innovations and usability are adopted by other developers and systems.

    What are the ripples that we don't see?

  5. Tha Jsta
    Posted 4 years ago #

    As a visually impaired person who uses the latest version of the JAWS For Windows screen reader I would like to know how much a priority are improvements specifically for keyboard and screen reader accessibility. I also use the latest version of the NVDA screen reader at times but judging by the dashboard and interface as a whole of version 3.3 it honestly does not seem anybody really cares about how the blind ‘see’ the WordPress backend. I might be wrong but version 3.2.1 was much more clean it seems. I hope the year of 2012 will be a year in which priority for improvements geared towards the blind and visually impaired are greatly emphasised.

    I read this and that about how everything looks visually but people need to shut off their monitors and disable their track pads for a day so they can fully experience what I experience. If the developers of WordPress awoke one day not able to see anything how many of them would be able to use WordPress to its maximum potential? I enquire to software developers all the time with whose applications I have problems and I just hope that makes people stop and really think about [1] if they must change anything; [2] what they must change; [3] how to implement those changes no matter what the cost. Why? Because everybody deserves fair access to WordPress [for sake of discussion here].

  6. esmi
    Forum Moderator
    Posted 4 years ago #

    it honestly does not seem anybody really cares about how the blind ‘see’ the WordPress backend

    Please see the recent discussions on http://make.wordpress.org/accessibility/

  7. Tha Jsta
    Posted 4 years ago #

    Nice read. I hope people go places with it.

  8. esmi
    Forum Moderator
    Posted 4 years ago #

    Please feel free to join in. It would be nice to get some feedback from a NVDA screen reader user instead of just JAWS users. :-)

  9. Tha Jsta
    Posted 4 years ago #

    I will try using NVDA whilst navigating the dashboard and other aspects of the backend instead of JAWS. Do you mean to post a comment on that accessibility post in respect to feedback?

  10. esmi
    Forum Moderator
    Posted 4 years ago #

    Yes please. The more feedback we can get from AT users, the better. It will all go towards increasing accessibility in future versions of WordPress.

  11. m3tabar0n
    Posted 4 years ago #

    also important: reduce memory usage/queries & increase overall speed (with 3.3, memory usage increased again by 2-3% with 128MB php memory)

  12. faddah
    Posted 4 years ago #

    thanks for offering the video town hall! looking forward to it.

    1. when/how/where can we check when it will be so we can tune in?
    2. at the town hall, in the new dev. features section, can you please make the first order of business to do live demo examples of how to use/access new features like Flexible Permalinks, the Post Slugs spec. characters fix, how to use/access the jQuery and jQuery UI 1.7.1 features, creating new admin screens in the WP_Screen API, and how to use the new features in the overhaul of the Editor API?

    that's what i'm looking for. thank you & looking forward to it.

  13. crtenbarge
    Posted 4 years ago #

    Native JSON support... I rely on a plugin that works great, but it feel it is irresponsible to build dependable infrastructure on a user contributed item that may break with the next update.

    And there might not be a big need, so how about an Automattic sponsored plugin?

  14. Graham Armfield
    Posted 4 years ago #

    Echo the comments about improved accessibility.

    I'm guessing you'll need more than that so will take a bit of time to analyse 3.3 and then post some suggestions.

    It's good to open up for thoughts now - accessibility should always been designed in, not just tacked on at the end.


  15. Adam W. Warner
    Posted 4 years ago #

    Related to previous commentator's search question...

    1. Are there any plans to give attention to enhanced search in Multisite? (options in each site on the network to search "entire network" or "search these specific sites on the network")

    2. Is it possible to include the ability to customize the user and site registration process in core? (there are many plugins out there that have attempted this and it seems that many have been abandoned or lack tight integration with core features)

    3. Are there any plans for hooks/filters for Widget Titles?

  16. Kim Gjerstad
    Posted 4 years ago #

    What was the toughest decision you guys made in 2011?

  17. Drew Jaynes
    Docs Czar
    Posted 4 years ago #

    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.

  18. Drew Jaynes
    Docs Czar
    Posted 4 years ago #

    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 wordpress.org?
  19. RogerWheatley
    Posted 4 years ago #

    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.
  20. Graham Armfield
    Posted 4 years ago #

    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: http://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.

  21. Graham Armfield
    Posted 4 years ago #

    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?
    9. 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.


  22. unrelatedmedia
    Posted 4 years ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Topic