Gutenberg and accessibility: personal thoughts and perspectives

There’s been some great (and not so great) discussion on WordPress’ project Gutenberg – the new WordPress editor experience that is being developed. I’m not going to recap everything here in this post. But before I share my own personal thoughts and perspectives on Gutenberg, I do want to share some links to some great posts on the current state (and issues) of Gutenberg’s accessibility.

So now my personal thoughts and perspectives (that’s why you paid good money to hear this, right? :-) ).

Most of Gutenberg’s accessibility issues stem from decisions made early on in the design and development process. Gutenberg’s focus has been primarily about a slick modern visual UX experience using modern JavaScript. Unfortunately this meant (and means) that other important aspects were not focused on as strongly. Let me make it abundantly clear that I do not believe Gutenberg designers and developers ignored accessibility or downplayed it. It just wasn’t the major focus.

The WordPress a11y (accessibility) team is a group of volunteers who meet weekly to discuss WordPress accessibility issues and how to resolve them. Note the keyword here is volunteers. Most are not WordPress core contributors or developers. We don’t really provide pull requests and patches as – for many of the volunteers – that’s just not our strength or skill set. Gutenberg further exacerbates this by adopting a modern javascript framework with all the tooling and workflows necessary for that – which makes for an interesting barrier to entry. Aside: I think the javascript focus will be good over the long run, but right now it’s a major pain point that cuts into what and how volunteers can contribute. Anyway, as Gutenberg became the focus for WordPress, the a11y team did it’s best to provide suggestions on how to resolve the many accessibility issues we discovered in personal and actual user testing. We tested, we filed issues, we participated in discussions. But we kept feeling like accessibility was not being appropriately balanced with the main Gutenberg focus. It didn’t help when updates broke fixed accessibility issues (regressions) and new features seemed to highlight the lack of basic accessibility testing prior to committing. It was disheartening. Things really came to a head with the 4.9.9 “nope-just-kidding” release. We were told 4.9.9 was being planned as a typical WordPress release and one of it’s focus’ would be addressing accessibility issues before Gutenberg landed. The team was pretty excited and we started a major review of the open accessibility tickets and divided them up among folks with time/capability to provide feedback on them. After a couple of weeks of this flurry of excited activity, we then heard that 4.9.9 release would now only focus on some PHP update work. The communication about this was less than ideal and left many of the a11y team shocked. I believe this was the tipping point. Soon thereafter Rian left, and others of us stepped back from helping out. Why should we volunteer and help out when it seems like our time and efforts were being wasted and unappreciated?¬†Fortunately it looks like the team is rebounding after taking stock of the situation and having a good and productive team discussion.

So here’s my final thoughts and opinions on Gutenberg and accessibility

  1. I don’t think Gutenberg ignored accessibility but it wasn’t a major focus and unfortunately this shows in the current product.
  2. Accessibility needs to be baked in from the start for best effect – Gutenberg unfortunately shows a tendency to try and bolt on accessibility after the fact, which never works as well in any experience I’ve had.
  3. Design expresses intent and if accessibility isn’t a major focus of the deign’s intent… well then, no amount of bolting on can hide or fix that. Again, not a ding on the Gutenberg designers but rather a ding on the project’s priorities and focus that I don’t think properly attached enough weight on accessibility.
  4. As it stands right now, Gutenberg probably needs at least 2-3 more months of strong accessibility and usability focused work to reach what I feel is a safe and acceptable “release-to-the-world” product level. I do have to give the team mad props for how much they’ve accomplished in such a short amount of time though!
  5. It is sad that the WordPress project decided against doing an accessibility audit on Gutenberg – I think this would have provided some great actionable feedback at a holistic level that the a11y team just doesn’t have time or bandwidth to provide.
  6. Going forward I would recommend that the WordPress project consider having releases led by a designer, developer and accessibility lead to ensure that all new features strike an appropriate balance between good design, modern development best practices, and accessibility.
  7. A special thanks to the WordPress a11y team of volunteers – you’re the best!

Updated theme

Now that WordPress 4.4 is out, I’ve decided to refresh my theme. I played around with twentysixteen and I am quite impressed. By itself it’s a very understated “blog” theme – but this makes it perfect for customization and extension. You can do this through either the built in WordPress tools or through a custom child theme. An evening of design and development later, I have a nice child theme which captures the look and feel I want.

While in its default appearance twentysixteen doesn’t look like much, a little bit of customizations can get you a very flexible and functional theme with just the right personality.

Customizing WordPress comments

The documentation on customizing WordPress comments is a bit sparse, particularly when compared to WordPress posts. I ran into this issue while building a web application built off of WordPress and wanted to use WordPress’ commenting system with some custom fields and styling. So here’s my attempt to address that.

  1. Make sure you have a comments.php template file for your theme – create one if needed. I recommend looking at _s for a good model.
  2. See the following code below – it should be pretty obvious with its inline commenting. Please excuse any WordPress code formatting issues.
  3. With this code we can now wrap your comment markup with our own tags and classes as well as display our own custom comment fields/data using get_comment_meta().
  4. The WordPress core comment-template.php file had the clues I needed to figure this out. I saw how they were structuring and coding things so I translated that code into my comments.php theme file, tested, and tidied it up until it worked. Now to the code…
 If the current post is protected by a password and
 the visitor has not yet entered the password we will
 return early without loading the comments.
if ( post_password_required() ) {
<?php // Now our comments area ?>
<div id="comments" class="comments-area">
    <?php //check to see if we have comments
    if ( have_comments() ) : ?>
        <h2 class="comments-title">
                printf( // WPCS: XSS OK.
                    esc_html( _nx( 'One comment on &ldquo;%2$s&rdquo;', '%1$s comments on &ldquo;%2$s&rdquo;', get_comments_number(), 'comments title', '_s' ) ),
                    number_format_i18n( get_comments_number() ),
                    '<span>' . get_the_title() . '</span>'
    <?php if ( get_comment_pages_count() > 1 && get_option( 'page_comments' ) ) : // Are there comments to navigate through? ?>
        <nav id="comment-nav-above" class="navigation comment-navigation" role="navigation">
            <h2 class="screen-reader-text"><?php esc_html_e( 'Comment navigation', '_s' ); ?></h2>
            <div class="nav-links">
<?php //comment navigation links ?>

                <div class="nav-previous"><?php previous_comments_link( esc_html__( 'Older Comments', '_s' ) ); ?></div>
                <div class="nav-next"><?php next_comments_link( esc_html__( 'Newer Comments', '_s' ) ); ?></div>

            </div><!-- .nav-links -->
        </nav><!-- #comment-nav-above -->
        <?php endif; // Check for comment navigation. ?>

    <ol class="comment-list">
            <?php if ( have_comments() ) : //possibly duplicative, but this works ?>
            <?php while (have_comments() ) : the_comment(); //the loop, but for comments ?>
            <li id="comment-<?php comment_ID(); ?>" <?php comment_class(); ?>>
            <article id="div-comment-<?php comment_ID(); ?>" class="comment-body">
                <footer class="comment-meta">
                    <div class="comment-author vcard">
                        <?php echo get_avatar( $comment->comment_ID ); ?>
                        <?php printf( __( '%s <span class="says">says:</span>' ), sprintf( '<strong class="fn">%s</strong>', get_comment_author_link() ) ); ?>
                    </div><!-- .comment-author -->

                    <div class="comment-metadata">
                        <a href="<?php echo esc_url( get_comment_link( $comment->comment_ID ) ); ?>">
                            <time datetime="<?php comment_time( 'c' ); ?>">
                                <?php printf( _x( '%1$s at %2$s', '1: date, 2: time' ), get_comment_date(), get_comment_time() ); ?>
                        <?php edit_comment_link( __( 'Edit' ), '<span class="edit-link">', '</span>' ); ?>
                    </div><!-- .comment-metadata -->

                    <?php if ( '0' == $comment->comment_approved ) : //is the comment in moderation ?>
                        <p class="comment-awaiting-moderation"><?php _e( 'Your comment is awaiting moderation.' ); ?></p>
                    <?php endif; ?>
                </footer><!-- .comment-meta -->

                <div class="comment-content">
                comment_text(); //the actual comment content 
                </div><!-- .comment-content -->

                comment_reply_link(); // the reply to a comment link
            </article><!-- .comment-body -->
                        <?php endwhile; ?>
            <?php endif; //closing out our comment loop 
        </ol><!-- .comment-list -->
        // If comments are closed and there are comments, let's leave a little note, shall we?
        if ( ! comments_open() && get_comments_number() && post_type_supports( get_post_type(), 'comments' ) ) :
        <p class="no-comments"><?php esc_html_e( 'Comments are closed.', '_s' ); ?></p>
    <?php endif; ?>

    <?php comment_form(); //the comment form ?>

</div><!-- #comments -->