Forum Replies Created

Viewing 15 replies - 1 through 15 (of 42 total)
  • Hi @sleeplessindc,

    Thanks for using Twenty Seventeen!

    Twenty Seventeen is a beautiful theme but it isn’t accessible. It’s not usable for corporate sites that have to comply with Federal government accessibility requirements. The description tags for this theme have “Accessibility ready” but that does not mean it is accessible.

    Members of the WordPress community tested the theme according to these accessibility standards. A theme can’t be fully accessible because much of that relies on a site’s content. But the theme is as accessible as it can be so if you need to make an accessible site, it can be done so.

    For accessibility, it has a lot of problems for screen readers and others who use tabbing for navigating a site and no screen reader help. The first tab takes me to the bottom of the first section and not to the top navigation menu, the second tab does nothing, the third tab takes me to the middle of the second section instead of the header for that section. The fifth tab takes me to the middle of the featured image and the top of the third section (better). The seventh tab takes me to the full screen featured image with no header. The third, fifth, and seventh tabs take you to various pieces of the second, third, and fourth sections but still doesn’t let users know where they are on the site or know they are still on the home page. The second, fourth, and sixth tabs do nothing. Non-exploring users are not going to know where they are or how to get anywhere else.

    I’m not able to replicate this using the theme’s official demo site. Tabbing for me goes in order of the content areas as I would expect.

    I’ll be getting a lot of “How do I log on?” questions. (It obviously never had an accessibility review, which I thought was required for all new themes or should be for all Twenty-something themes to meet coding standards.)

    If logging into WordPress is important to your users, you can add it as a link to your main menu with Custom Menus in the Customizer. If you need help on that, see this guide.

    Hi @aliaamir,

    Thanks for using Twenty Seventeen! Are you wanting to make changes to the HTML associated with the date, or do you just want to show the last modified date instead of the published date?

    That would be awesome to have, for sure! This isn’t really possible within the theme. But there’s ongoing work within WordPress to make this type of thing possible in the future on any page.


    1) How do we change the following header variables for the front page?

    Those values can be modified in a child theme with a filter. Like this, as an example. Drop that into a child theme’s functions.php file:

    function childtheme_custom_header_setup() {
    	add_theme_support( 'custom-header', apply_filters( 'childtheme_header_args', array(
    		'width'                  => value,
    		'height'                 => value,
    	) ) );
    add_action( 'after_setup_theme', 'childtheme_custom_header_setup' );

    2) How do we change the above header variables for the individual post and pages, and also groups of posts such as all posts under one category?

    This is a bit custom. I can’t write all that code for you, but it should be possible with the proper conditional logic, like is_page. You can use the above function as a starting point.

    Happy theming!


    I see. So essentially, any of the /inc files from the parent theme will still be pulled in from the parent theme, since the last lines of the parent functions.php file runs after the child theme’s functions.php file. And because of this, creating a /child-theme/inc/template-functions.php file is essentially useless. Correct?

    Right, those parent theme functions will run. Simply overriding the file doesn’t make them not run. Glad you got it.

    (still find it confusing why the template functions are in a separate file, not just in functions.php, but I’m sure there’s a lengthy trac debate somewhere that resulted in this decision)

    This is mainly to break things up and not have the functions.php file be really long.

    functions.php has default/Core functionality.

    template-functions.php has additional features to allow styling of the templates. Mostly behind the scenes stuff.

    template-tags.php has custom template tags for the theme. This is actual markup rendered on the front end.

    Hi @hopetommola,

    Good question. This can be tricky to understand at first.

    The reason simply overriding in a child theme doesn’t work is because a child theme’s functions.php run first, then the parent theme’s functions.php. So in your case, Twenty Seventeen’s twentyseventeen_body_classes() still runs, overriding your changes.

    You need to pay attention to a filter hook’s priority. See this article.

    That can be changed to make sure your function runs after another function hooked to the same filter. Check out this code, with comments explaining it.

     * Adds and/or removes custom classes to the array of body classes.
     * Uses 11 priority to run after parent theme. Default is 10.
     * @param array $classes Classes for the body element.
     * @return array
    function childtheme_body_classes( $classes ) {
    	// Removes has-sidebar class from custom post type.
    	// If the sidebar is active and a single post of my-post-type is viewed.
    	if ( is_active_sidebar( 'sidebar-1' ) && is_singular( 'my-post-type' ) ) {
    		// If the has-sidebar class is in the $classes array, do some stuff.
    		if ( in_array( 'has-sidebar', $classes ) ) {
    			// Remove the class.
    			unset( $classes[ array_search( 'has-sidebar', $classes ) ] );
    	// Give me my new, modified $classes.
    	return $classes;
    add_filter( 'body_class', 'childtheme_body_classes', 11 );

    This way, only the part of the function you need to modify is changed in the child theme, and the parent theme does the rest.

    Make sense?

    Hi there @bharatk,

    Great question!

    This is probably best accomplished in a plugin. Like this one, for example.

    Your code won’t work because the'default-image' value is different than the custom header image value displayed on the front end. WordPress looks for an uploaded image first, and if not, falls back to the default image. It only knows of one custom header image value at a time. That’s why it’s best that a plugin tackles this kind of thing, because each page could need it’s own custom header value.

    That said, if you’re looking for just this quick change, you can drop this into the new Additional CSS panel in the Customizer:

    /* Hide the inline custom header image on the front page. */
    .twentyseventeen-front-page .wp-custom-header img {
    	display: none;
    /* Place a new one, via background. */
    .wp-custom-header {
    	background-image: url(/wp-content/themes/twentyseventeen/assets/images/header.jpg);
    	background-repeat: no-repeat;
    	height: 100%;
    	background-size: cover;

    That should work, no child theme needed. 🙂

    Hey Galen,

    Thanks for the report! Sami is right – the offending markup is related to how Twenty Seventeen uses two methods to link to a SVG. One method is from version 1.1 of the SVG spec, and the other from version 2. We used both because of the way current browsers support one and not the other. It’s valid HTML though, even if some validators haven’t caught up yet. See this part of the spec.

    Hello @bstofko!

    Thanks for the report!

    I was able to see what you mean with your example code – much appreciated!

    This isn’t really a bug though. The z-index settings in the CSS work now. In general, I try to observe these rules for z-index:

    Only use them when needed.
    Don’t go too high in number, except for items that should always be on top.
    Try to make them logical.

    I’d rather not add more z-index CSS to account for edge cases. If someone needs to start adding z-index rules in the content, or to the theme, they’re likely comfortable enough to modify things to fit their needs.

    Thanks, Mika! That’s super helpful to know.

    Most of the testing and Trac-ing I’ve done in the past has been before the release candidate phase, so I wasn’t sure of the preferred workflow. 🙂


    Sorry about that, I wasn’t thinking and thought this is where you all wanted everything at this point.

    Hey there!

    Thanks for the suggestion! I’m a member of the WordPress Accessibility Team, so hopefully I can answer your question.

    I don’t see WordPress adding any kind of keyboard shortcuts for the general Admin area. All major screen readers support jumping around the page via different elements, like links, form controls, ARIA roles and others. So a user should be able to navigate easily and quickly in the use-cases you point to in your post.

    WebAIM has some nice articles on screen readers and the shortcuts within them. Check out:

    Also, if you’re interested in making accessibility in WordPress better, join us here:

    Jetpack is definitely a big plugin, and some things aren’t enabled by default, or very intuitive. I believe you find the configuration toggles you’re talking about in each individual gallery as an option when you insert it into a post or page.

    If you want to go the custom route, maybe give Masonry a try. It’s a custom jQuery library that WordPress includes by default. It will take some custom coding to get it working with your galleries, but it’s possible.

    Good luck!

    Hi there,

    Your header.php file should look like this sample, if I’m understanding you correctly.

    When you activate a new theme, even a child theme, you need to set your menus in the Menus section in the WordPress administration area.

    Give that a try and see if it helps.


    You might want to check out the Jetpack plugin. It does what you’re looking for, as you can see in this post about the feature.

Viewing 15 replies - 1 through 15 (of 42 total)