Time to Test Twenty Fifteen!
Today, Twenty Fifteen landed in /trunk.
@iamtakashi and others have worked really hard to make this first pass accessibility-ready
from the start.
I’ve done an initial accessibility-ready
review and advised on a few bug fixes. But we still should bang and bend this lovely theme from an accessibility perspective.
Note: This theme has different color schemes, so keep in mind only the default one needs to meet the accessibility checks.
We’d love to find a more elegant solution for the focus styles on the main navigation links.
If you’re not comfortable filing a ticket, just comment here and we’ll consolidate them into feedback on future tickets.
Please post all feedback here. If you are using assistive technology to test Twenty Fifteen, please indicate exactly what software you are using and web browser — including the version number, if possible.
To test Twenty Fifteen:
- Install WordPress locally.
- Download and install the Beta Tester plugin.
- Configure the Beta Tester plugin and update WordPress.
- Activate Twenty Fifteen and test to these standards.
October 15, 2014: Updated post with instructions on how to get Twenty Fifteen. Updated with additional feedback instructions.
Rian Rietveld 8:56 am on October 15, 2014 Permalink
I suggest we use next test meeting to look at Twenty Fifteen together.
That will be on Monday October 20 from 17:00 UTC on IRC #wordpress-ui
David A. Kennedy 1:37 pm on October 15, 2014 Permalink
Great idea, Rian!
It would be great if people tested before then and came to the meeting with anything that needed discussion.
Rian Rietveld 2:49 pm on October 15, 2014 Permalink
+1
nsousa 10:10 am on October 15, 2014 Permalink
Hi,
I’d like to test the theme. How can I do it?
Is the theme for download: changeset_29892.zip? Can I import it to wordpress 4.0? If not, how can I access the twenty-fifteen theme?
I use screen-readers. I tried to follow the information in:
https://core.trac.wordpress.org/changeset/29892
but didn’t got it!
Some clues are welcome.
Regards,
NSousa
David A. Kennedy 1:39 pm on October 15, 2014 Permalink
Welcome @nsousa!
I’ve updated the post with some instructions on how to get Twenty Fifteen.
If you have more questions, just ask!
Sharon Austin 7:12 pm on October 15, 2014 Permalink
Congratulations on a beautiful, beautiful gorgeous new theme. The hard work is obvious, and really appreciated.
Even more appreciated is how everyone is working together to ensure an accessible theme.
One thing that jumped out at me immediately, however, is the visual confusion that results from having a header image behind the default menu. I can tab to all the items, but I can’t see them visually because the background “clutters” the visual landscape.
Also, as is noted in ticket #15926, there is no way to add alt tags to the header image.
Beautiful theme, guys and gals!
Sharon Austin 8:22 pm on October 15, 2014 Permalink
Here’s a link to an example pageshow you what I’m talking about regarding visual clutter.
But I want to emphasize that I think this is a BEAUTIFUL theme! Thanks again!![:-)](https://webarchive.library.unt.edu/dentonfracking/20141030081134im_/https://make.wordpress.org/accessibility/wp-includes/images/smilies/icon_smile.gif)
David A. Kennedy 11:51 pm on October 16, 2014 Permalink
That’s a good point Sharon, but there is an option in the Customizer that allows users to change the text color for the Header and Sidebar. So depending on the image, users can change things.
In this case, at least, adding alt text is less of an issue because the image is added via CSS as a background. So hopefully, users understand these images should really only be decorative and not content.
Sharon Austin 12:30 pm on October 17, 2014 Permalink
“In this case, at least, adding alt text is less of an issue because the image is added via CSS as a background.”
….in that case, then, sir THAT….is outstanding!![:-)](https://webarchive.library.unt.edu/dentonfracking/20141030081134im_/https://make.wordpress.org/accessibility/wp-includes/images/smilies/icon_smile.gif)
Bram Duvigneau 9:04 am on October 16, 2014 Permalink
Just had a first quick look with a screenreader. I’m not sure if putting all the navigation before the content in code order is a good idea. Yes, I know there is a skip to content link and that’s good, but not everyone will use that.
David A. Kennedy 12:19 am on October 17, 2014 Permalink
Hey Bram,
Thanks for your thoughts!
How would that be different than having the navigation toward the top of the page, like in any other theme? Is it because the optional sidebar is below the main navigation?
nsousa 2:25 pm on October 20, 2014 Permalink
Hello David,
I agree with Bram. It would be better if sidebar comes after the content in the code. My comments about Twenty Fifteen theme below.
I already have some comments about Dashboard pages, but I promise I’ll try to make a new ticket!
Homepage issues
there should be a higher contrast.
Suggestions
See examples:
http://iact.ipleiria.pt/en/
my site in portuguese:
http://www.comacesso.pt
I’ll back if I’ve more issues or suggestions.
Regards,
NSousa
Rian Rietveld 3:21 pm on October 20, 2014 Permalink
Hi @nsousa,
To my opion the H1 should be the post/page/archive title and only on the homepage be the site-title, to avoid that all pages have the same H1, agree on the heading description, that’s no heading.
Why shouldn’t the Widget titles be written in capital letters?
Where is the contrast to few?
I disagree that an accessibility menu should be added, to my option the theme is already good for contrast and colour, and because the font sizes are relative, a Ctr+/Ctr- works perfectly.
KatherineMancuso 5:25 pm on October 20, 2014 Permalink
I agree with @rianrietveld on the accessibility menu point. An accessibility menu including the features @nsousa wants (color, contrast, zoom) can currently be added to any theme by using the WP Accessibility plugin (https://wordpress.org/plugins/wp-accessibility/) by Joe Dolson.
While it would be interesting to have it be native in the theme, this would be asking for a major change to the theme which probably won’t be able to be implemented in time for release. Also, this feature reflects WCAG 2.0 compliance at the AAA level, and the accessibility laws in most countries request AA compliance. Therefore, this represents a “nice to have” but not an essential for most accessible sites, and should be a lower priority in terms of feature requests than issues which relate to AA compliance.
Rian Rietveld 3:01 pm on October 20, 2014 Permalink
Hi All,
Hereby my a11y testing results of Twenty Fifteen, also @bramd did a screen reader check.
Haven’t got solutions for everything, but plan to open or add to tickets after the IRC test session today (Oct 20, 2014, 19:00 UTC)
Tested the nightly build WordPress 4.1-alpha-20141019.
Tested against WCAG 2 AA guidelines and WordPress a11y guidelines.
Also did W3C validator checks.
This test is not complete, just did what I had time for. today So If you see more, please comment.
First of all, WOW, what a beautiful theme!
Love the details and like the way next previous posts are done and keyboard usability of the sub menu’s and also the social media menu. And it shows that there was efford to get a11y done right.
Ok, here it is, Issues found:
Heading structure:
This is a really big disappointment, an overload of H1’s that leads to an HTML outline that makes no sense al all.
Yes, it is all HTML5 compliant, but is also in heavy dispute for more than a year now, see for example:
http://www.paciellogroup.com/blog/2013/10/html5-document-outline/
This means: one H1 per page and the rest meaninghull devided into h2/h3/h4 etc headings.
To my opinion this is a path that we must not go.
At least change the widgets to an H2 in functions.php
I agree with @nsousa, this should be done semantically correct.
Also: make the tagline not a h2 but a p, it’s not a heading of any content whatsoever.
And: add an H2 before a nanigation with, for example, the menu titel.
Keyboard accessibility:
Focus:dotted line, that’s OK
A link with an image insidet gets no dotted line on focus in Safari, maybe add in CSS something like
a:focus, a:focus img {
outline: thin dotted;
}
W3C validation of HTML:
As expected:
“Consider using the h1 element as a top-level heading only (all h1 elements are treated as top-level headings by many screen readers and other tools).”
W3C validation of CSS:
The validator only complains about new CSS3 functionallity, not an issue for accessibility to my opinion.
Like width and height calc don’t parse (yet).
Colour contrast:
Colours of the default theme are all WCAG 2 AA compliant as far as checked
Menu’s:
The main menu works good with keyboard only, also with a submenu.
But with a screen reader it gives problems and the structure is’t read well.
Button is block element, can’t be placed inside an inline element such as a.
The text inside the button is expanded or collapse, but it’s not clear what is expanded or collapsed.
Needs another workaround for screen reader.
suggestion: underline menu links on hover to make it more clear they are clickable.
Next -previous:
The background of this link is the featured image of the post, which is nice, when the image is too white, the text can’t be read properly.
Suggestion:
.post-navigation .has-post-thumbnail a::before
background-color: rgba(0, 0, 0, 0.6);
Sidebar:
It’s already said in comments above, and I agree, putting the sidebar before the content seems weird and not usable.
The toggle on the sidebar is’t very clear for screen reader users
Here the use of expanded/collapse is appropriate.
Header Image:
Header image is in fact an overall body background image
How to properly add a logo or such?
Search form:
A label has to have a for to the ID of the input field.
The submit button has class display: none; why?
Is there any use for adding the submit? because this way it isn’t displayed in any device or AT.
There is a title=”Search for:” in the input field. Why? It doesn’t improve accessibility at all.
My suggestion:
label for=”search-field” class="screen-reader-text">Search for:</label
input type="search" id=”search-field” class="search-field" placeholder="Search …" value="" name="s">
404 template:
Text: “Maybe try one of the links below”.
What links?
Archive template:
The thumbnail alt text is image alt, should be post title.
Comments template:
Done correctly in the theme, but not in default WP, so maybe no issue here
If there is no comment the “Leave a Reply is a H3 (default WP), for there is one ore more comments the comments title is an H2 (which is correct).
For me, the biggest issue is the heading structure.
nsousa 4:54 pm on October 20, 2014 Permalink
Hi,
Capital letters are more difficult to read by persons with reading difficulties and low vision.
Besides that, if you read a word in capital letters with screen reader in a foreign language – and for some cases even in the sites’ language – it will spell the word instead of reading it normally.
At least, make capital letters through CSS.
Yes, the theme is well done, but we can improve it more!
Ctrl + plus is known by you and by me, but there’s still many people who doesn’t know it.
Bram wrote:
add an H2 bevore a vanigation with for example the menu titel.
It is not used anymore because there is role navigation.
Headings should be used for sections structure and not for navigation.
Good meeting,
NSousa
Rian Rietveld 6:37 pm on October 20, 2014 Permalink
Capital letters are made in the CSS here, so screen readers don’t have trouble with it, the HTML is lower case.
I’m not screen reader expert, but @bramd is, so I leave you two to fight over the navigation heading issue![:-)](https://webarchive.library.unt.edu/dentonfracking/20141030081134im_/https://make.wordpress.org/accessibility/wp-includes/images/smilies/icon_smile.gif)
KatherineMancuso 5:15 pm on October 20, 2014 Permalink
I agree with Rian that it is essential to fix the heading structure. In particular, there will be major benefits for both SEO & accessibility if there is only one H1 per page.
nsousa 10:01 pm on October 20, 2014 Permalink
Hello,
Rian wrote:
“To my opion the H1 should be the post/page/archive title and only on the homepage be the site-title, to avoid that all pages have the same H1,”
NS. Comments about headings below. I sent it by E-mail before participating in the group discussion.
I also agree with you, but you should not make a front page structure different from the other pages.
Bram wrote:
“Header Image:
Header image is in fact an overall body background image
How to properly add a logo or such?”
NS. I’ve also the same question.
My comments about headings:
Regarding heading’s hierarchy I’ll try to explain it better.
At the moment, site, page and articles titles are defined as H1.
The sections’ titles, E.g. Categories; activities; etc. are defined as
H3. So it brokes the hierarchy.
Suggestion 1:
Suggestion 2:
articles’ and Sections titles as H2.
Suggestion 3:
new content title defined as H2; define articles’ as H3; Sections
titles as H2.
In the future, it would be great if we could offer an option – very
important to the Non-coders developers – to choose if this new content
title should be hidden or not and to choose one of the hierarchies
proposed above.
Issue 2 – site’s Description defined as H2 and hidden
In twenty-thirteen the Site’s title is defined as H1: Ok;
Description is defined as H2: there’s no need to be a heading, since
it is not a content/section’s title.
In twenty-fourteen even if it is chosen not to be displayed, screen
readers read both site’s title and description. Besides that,
Description is read not just after site’s title as in twenty-fourteen
Good Work,
NS
Rian Rietveld 10:06 am on October 21, 2014 Permalink
Hi @nsousa,
Thanks for your feedback!
To my opinion the H1 should be what’s the page is about, so, the post title for a post for example. Leaving the site title as H1 results in the same H1 for every page on a website and I think that not semantic right and also bad for accessibility and SEO.
Kind regards,
Rian
Andrea Fercia 11:37 pm on October 20, 2014 Permalink
Hi, I’m very interested in this point from @nsousa:
> Navigation role: complementary information should involve all the widgets from the sidebar and not each widget. It is too much noise to a screen reader user!
I’ve noticed this using NVDA and pressing “d” to navigate through ARIA landmarks and yes, it’s very annoying. It would be great to have some feedback and user testing on this specific issue. To test, just remember to have a bunch of widgets in your sidebar![:)](https://webarchive.library.unt.edu/dentonfracking/20141030081134im_/https://make.wordpress.org/accessibility/wp-includes/images/smilies/icon_smile.gif)
With NVDA you can also get a list of ARIA landmarks in a page pressing NVDA key + F7 which will open an “Elements list” popup with 3 lists: Links, Headings, Landmarks.
This is something that is used not only on Twenty Fifteen but comes from the starter theme _s (or underscores) so it would be a very important change also for the next default themes.
About ARIA landmarks, see as reference:
http://www.paciellogroup.com/blog/2013/02/using-wai-aria-landmarks-2013/
where there’s a clear example of a WordPress theme with just 1 complementary region.
See also the structure of Bruce Lawson’s site mentioned in the article:
http://www.brucelawson.co.uk