Quick Accessibility scan of the WordCamp Nijmegen 2018 website.

Date review: 12 Juli 2018

Website: 2018.nijmegen.wordcamp.org
Out of scope: Jetpack addons, the like system in the schedule, the ordering system and the cookie warning. Issues there will be reported to WordCamp Central.

This is a short review of the accessibility of the website for WordCamp Nijmegen 2018. As this is a quick scan,  I didn’t add the why. All this info can be found in the WordPress Accessibility Handbook Best Practices. If the organization of Nijmegen needs help with this, please let me know.

Update July 24: The Nijmegen team fixed the issues that could be fixed in the site. So that’s great!

Found issues

Use of colour

The links in the text are red. They miss an underlining.

Colour contrast

The following elements have a to low colour contrast between text and background:

Orange #fb9634 on white #fff is 2.2.

Used in:

  • Active menu
  • Ticket order image in the main menu

Grey #aaa on white #fff is 2.32

Used in:

  • Forms: the text “(verplicht)”
  • Entry-meta links with a post

Keyboard accessibility

The link “bestel je ticket” is hard to reach with a keyboard, as it’s added to the footer and positions absolute in the top of the page.

The close en accept of the cookie warning misses a focus style.

Heading structure

Header

For every page, in the header here is the code:

<a class="home-link" href="https://2018.nijmegen.wordcamp.org/" title="WordCamp Nijmegen 2018" rel="home">
 <h1 class="site-title">WordCamp Nijmegen 2018</h1>
 <h2 class="site-description">30 augustus t/m 1 september: hét WordPress-evenement voor Nijmegen en omgeving!</h2>
</a>

The following needs to be addressed:

  • This H1 now is not unique for every page and is not telling what the page is about.
  • The site description is a heading now, it should be a paragraph
  • Title attributes on links are discouraged in WordPress

An example of an excellent header is the WCEU 2018 website header. This has a good and logical heading structure.

Homepage

On the homepage, every post has an H1, resulting in multiple H1s for that page. Best practice is to have one H1 per page view, telling what that page is about.

Footer

In the footer the text “Ondersteund door WordPress” is a heading. This should be a paragraph.

Widgets

Widget have a H3 heading, resulting in a missing H2 heading in the heading order.

Headings without content

In some pages an empty H2 is present, like:

<h2 id="aanmelden"></h2>

Code

Again about:

<h2 id="aanmelden"></h2>

This is sometimes places multiple times on a page, resulting in a double id. Ids should be unique for a web page.

Content

Link texts

Don’t use a URL or “here” as link text, but describe in the link text the destination of the link.

Change for example the text:

Wil je op de hoogte blijven van het laatste nieuws rondom WordCamp Nijmegen? Volg ons dan op twitter via https://twitter.com/wordcampnmgn en #WC024. Ook op Facebook kan je ons vinden. Je gaat dan naar facebook.com/wordcampnijmegen of ons event via https://www.facebook.com/events/172282166768794/.

In:

Wil je op de hoogte blijven van het laatste nieuws rondom WordCamp Nijmegen? Volg ons dan op Twitter en via de hashtag #WC024. Ook op onze Facebook pagina kun je ons vinden of via ons Facebook Event.  

 

Going Dutch

This spring comes with change. On May 14th I started working for Level Level, a Dutch WordPress Agency in Rotterdam.  

I left Human Made. And that was a painful decision. But I believe it was the right decision for me to take. Remote working is not for everyone. And I realised, it is also not for me.

Human Made is an absolute wonderful company, my HM colleagues are talented and kind. I did development and a11y reviews for client projects. Human Made gave me time to work on WordPress core, lead the accessibility team, speak at WordCamps, publish research. A true dream job.

But in my heart I was very alone and tired. All the communication in English, working with different time zones, asynchronous communication in Slack, it wore me out. This is me by nature, not the fault of anyone here. Other people thrive on remote working.

The Dutch WordPress community is very close. I always feel at home and between friends in a local WordCamp or Meetup. I realised: this is where I belong. So when Taeke Reijenga, the CEO of Level Level, asked me to work for him in Rotterdam, I said yes.

With Level Level I’m going to join the developers team, teach web accessibility and do reviews. In Rotterdam, not far from where I live.

Besides that I can spend time on the WordPress Accessibility Team; I will continue to work with the Accessibility Team; speak and work at WordCamps and meetups, that will not change.

I’m very grateful for what I’ve learned in my time with Human Made. I’ve made some good friends and I hope to hug and work with them in future WordCamps.

Entering a new chapter in my career now. Feeling good 🙂

Keyboard test Gutenberg, a first try

How does Gutenberg 2.3 perform with keyboard only? I’ve set up a test and looked for issues. The test, the results and a YouTube with the test are included.

Goal of this Gutenberg test is to see where currently the problems are and collect data to write a manual for keyboard users. Also I want to learn and construct a standard test for other assistive technology. The test is set up to do the most common tasks for a content manager (who is not a developer). Like add and modify text, headings, images, lists, tables, and embeds.

The test results are part of the large scale Gutenberg  testing for Accessibility, organized by The WordPress Accessibility team.

Continue reading “Keyboard test Gutenberg, a first try”

Accessible custom styled form elements

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, but are they accessible? Here’s my point of view.

The challenge

HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, based on two different approaches:

  1. Hide the form elements from sight and apply the styling on a container or related element
  2. Hide the form elements from sight and rewrite the functionality, using styleable elements like <div>s and JavaScript

Continue reading “Accessible custom styled form elements”