Distributing speaking time can be tricky when meeting face to face, but it is usuallly worse in virtual meetings. Especially those spanning long distances. In my current team, I learned how queues in remote meetings can make them better for everyone. Here’s how we queue.

Queues matter

As a Dutchman in Bristol, UK, where I lived for ~3 years, I’ve had to learn how to queue. Growing up Dutch teaches one about cycling, consensus and clogs, but it leaves most folks behind on the queuing front. Skills are sometimes culture-based. You see, when a Dutch train arrives, people will try and stand close to the entrance. When the door opens, they will try and push themselves in before others. Brits do this differently: they first look for a queue, form one if none exists, and so on. Most likely there are still significant gaps in my understanding of it all.

Anecdotes aside, fair queuing is important. In any kind of organisation. In a recent interview, a female Dutch cabinet minister shared how the prime minister always seemed to let male counterparts talk earlier and longer. It was resolved with promises to improve, but this is way too common in meetings everywhere. Some talk a lot, others find it hard to join in (I’ll say that I’ve been both depending on circumstances).

The queue bot

Since I started working with the W3C, I’ve learned to love a meeting management system that is old, but very effective. Meetings at the W3C are generally scribed: one or more people volunteer to write down who says what. This happens on IRC, which is a bit like Slack, but much older. It’s also not just a service, but an open and long proven protocol for which you don’t need (but can have) an account. That’s useful for us, as our meetings typically involve people from outside our own organisation.

Anyway, in W3C meetings, the group usually shows up both on some video conferencing platform and simultaneously on IRC. When the meeting is ongoing, if you want to speak, you type:

q+

This puts you on the speaking queue. Other meeting attendees will generally be on IRC, too, and see this. The chair of the meeting (usually) ensures that people speak in queue order—those who jumped on first, get to speak first. Unless there are practicalities, like the subject they were on queue for.

If you want to remind yourself or others of the subject or your point, you can write:

q+ to ask about comms plan

There are lots of hacks, like qq+ (put me on the queue, but skip to the front), and there is a bot in the meeting that will keep track of who’s on queue. If anyone asks q?, the bot responds with a list in the right order. I know, a machine that learns!

The bot, called Zakim, was named after a bridge near the Massachusetts Institute of Technology, I learned recently. In turn, that bridge is named after a human rights activist. It does more than just queuing, it also manages meeting agendas and who’s attending.

Wrapping up

Meeting with this system doesn’t guarantee equal talking time, nor does it pretend to, but the visible method of queuing is really nice to have, especially in virtual meetings. I wonder if other organisations have tools like this, and if not, why not?

---

The post Queuing up was first posted on hiddedevries.nl blog | Reply via email

Distributing speaking time can be tricky when meeting face to face, but it is usuallly worse in virtual meetings. Especially those spanning long distances. In my current team, I learned how queues in remote meetings can make them better for everyone. Here’s how we queue.

Queues matter

As a Dutchman in Bristol, UK, where I lived for ~3 years, I’ve had to learn how to queue. Growing up Dutch teaches one about cycling, consensus and clogs, but it leaves most folks behind on the queuing front. Skills are sometimes culture-based. You see, when a Dutch train arrives, people will try and stand close to the entrance. When the door opens, they will try and push themselves in before others. Brits do this differently: they first look for a queue, form one if none exists, and so on. Most likely there are still significant gaps in my understanding of it all.

Anecdotes aside, fair queuing is important. In any kind of organisation. In a recent interview, a female Dutch cabinet minister shared how the prime minister always seemed to let male counterparts talk earlier and longer. It was resolved with promises to improve, but this is way too common in meetings everywhere. Some talk a lot, others find it hard to join in (I’ll say that I’ve been both depending on circumstances).

The queue bot

Since I started working with the W3C, I’ve learned to love a meeting management system that is old, but very effective. Meetings at the W3C are generally scribed: one or more people volunteer to write down who says what. This happens on IRC, which is a bit like Slack, but much older. It’s also not just a service, but an open and long proven protocol for which you don’t need (but can have) an account. That’s useful for us, as our meetings typically involve people from outside our own organisation.

Anyway, in W3C meetings, the group usually shows up both on some video conferencing platform and simultaneously on IRC. When the meeting is ongoing, if you want to speak, you type:

q+

This puts you on the speaking queue. Other meeting attendees will generally be on IRC, too, and see this. The chair of the meeting (usually) ensures that people speak in queue order—those who jumped on first, get to speak first. Unless there are practicalities, like the subject they were on queue for.

If you want to remind yourself or others of the subject or your point, you can write:

q+ to ask about comms plan

There are lots of hacks, like qq+ (put me on the queue, but skip to the front), and there is a bot in the meeting that will keep track of who’s on queue. If anyone asks q?, the bot responds with a list in the right order. I know, a machine that learns!

The bot, called Zakim, was named after a bridge near the Massachusetts Institute of Technology, I learned recently. In turn, that bridge is named after a human rights activist. It does more than just queuing, it also manages meeting agendas and who’s attending.

Wrapping up

Meeting with this system doesn’t guarantee equal talking time, nor does it pretend to, but the visible method of queuing is really nice to have, especially in virtual meetings. I wonder if other organisations have tools like this, and if not, why not?

---

Originally posted as Queuing up on Hidde's blog.

Reply via email

My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

Sometimes, ‘accessible’ means only partially accessible. That’s a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?

Sometimes, ‘accessible’ means ‘has a bunch of ARIA attributes’. In the best case ‘has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard’. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?

Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components.

---

Reply via email

My mission in web accessibility is to make it easier for people who want to create accessible interfaces. There are many means to that end, from building good understanding of how people with disabilities use the web to providing clear and well-tested code examples.

I mean, if you understand how people use the web with a mouse, it is easier to design a mouse cursor that works for them, or write the code to implement one. This also applies to keyboard, switch controls, voice navigation, touch and screenreaders.

I like the power of reusable components, as they allow for baking accessibility into components, whether in frameworks or vanilla. One day there may be better UI controls in the web platform and/or more accessible defaults in browsers. Now, teams often build their own components (see Smashing’s guide for tips). Of course, not all project teams can always build their own components every single time. This is not ‘Nam, there are deadlines. And so, we commonly use third-party components like custom selects, autocompletes and date pickers.

In this post, I will warn you about blindly trusting accessibility claims and share some questions to ask with each third party component you consider for your project.

“Accessible” doesn’t say it all

As accessibility-aware developers, we may look specifically for components that are accessible. Maybe we search the web for ‘accessible X’. If you do that, be aware that there are more components that claim to be accessible than components that actually are usable or great to use for people with disabilities.

Sometimes, ‘accessible’ means only partially accessible. That’s a problem, as accessibility is about making interfaces work for people with a broad range of disabilities (see Diverse abilities and barriers). For instance, what to think of a widget that was made to work with a keyboard, but breaks badly when zoomed in? It has perfect colour contrast, but no HTML semantics? The screenreader experience is excellent, but it is tricky for users who control their system with voice?

Sometimes, ‘accessible’ means ‘has a bunch of ARIA attributes’. In the best case ‘has ARIA attributes and keyboard behaviours that exactly meet the ARIA standard’. Sometimes that it is a 1:1 implementation of the ARIA Authoring Practices Guide (APG), a set of examples (not a standard) written by a subgroup of the ARIA Working Group. The APG is an excellent resource if you want to know how to write technically correct ARIA. But… it does not make claims about screenreader compatibility, see ARIA-AT and/or a11ysupport for that. It also does not make claims about user experience, so always be sure to test the patterns with people, or read blog posts from others who tested with people. Lastly, it also does not recommend whether to use ARIA or go HTML-only… it is just about using ARIA. Sometimes, HTML-only patterns are easier to understand for end users. More ARIA does not mean more accessibility.

Sorry, I realise none of this makes it particularly easy to find accessible components, but I want to be honest. In any case: don’t give up. Remember what Léonie Watson once said about accessibility: “it doesn’t have to be perfect, it just has to be a little bit better than yesterday”. The more research we do, the better informed our choice will be.

Some questions to ask

If we want to have a little more certainty about the accessibility of a component, there are some checks we can do.

How did they test?

It’s good news when a component’s website explains how a component was tested. Usually browser support is listed, sometimes support for assistive technologies like screenreaders is included, too. Maybe they’ve done formal WCAG testing or they have some sort of checklist. They may be running only automated tests, which are good and useful, but limited to things that can be automatically tested (most of WCAG cannot be). Information about the type(s) of testing can help inform us about the accessibility of a component.

Who did they test with?

Testing accessibility is ultimately not about technology, though, it is about making sure the pattern works for people with disabilities. If we look at a component, can we find whether they specifically included people with disabilities? Was a broad range of disabilities included?

Representation matters; accessibility often requires testing a broad range of people, disabilities and assistive devices. When Marcy Sutton user tested patterns for accessible routing, users of screenreaders, voice navigation and switch controls had varied experiences and comments (see What we learned from user testing accessible client-side routing).

Are they open about pros and cons of their approach?

Accessibility is not always one size fits all, sometimes there may be caveats to an approach, there may be things that may still be experimental. It’s a good sign if the component developer is open about this. Sometimes there will be an accessibility statement with known issues and planned fixes.

Who created them?

Sometimes I put extra trust if the people or organisations that created components work for the public good and/or in accessibility. Government-backed component libraries like the gov.uk design system, the New Zealand government design system and the US government’s design system contain gems. So do pattern libraries created by accessibility practitioners like Deque’s Cauldron and Tenon UI.

More indicators

I also asked around on social media! Below are some of the tips that were shared there (❤️ thanks all!)

Look at GitHub issues

Marcus recommended to look at GitHub issues about WCAG or accessibility, “their presence would be a warning sign”. Thea said it can also be a “sign that people care”, she suggests looking at activity and discussions on issues. Mitchell agreed: “the quest for optimal usability and interoperability is never done”. Mallory +1’ed too and looks at how authors respond.

Accessibility as an integral part

Sara warned to be wary of treating accessibility as a separate feature rather than an integral part of the work. If there is an accessible version and a non-accessible version, they’ve probably failed that test!

Find specifics

Bogdan would look for specifics of the accessibility claim: which version and level of WCAG are we talking? He and Weston also said to look for which specific screenreaders were tested.

Perform basic checks

Various people said basic checks can give away a lot: do the docs even mention accessibility (Oscar), is there sufficient colour contrast (Martin), does it work with just a keyboard (Brent and Eric)?

Find out about committment

Heather recommended to look at the website of the component; obvious accessibility issues there say something about the claimed commitment to accessibility.

Yakim said we should look at the testing method to gauge how sustainable accessibility efforts are: “are they ongoing and proactive, or are they reactive?”

In his blog post Be wary of accessibility guarantees of accessibility vendors, which is more about accessibility of tools in general, Adrian recommends going on Twitter and searching the company name combined with the #a11y hashtag.

Customisability

If nothing is perfect, why not improve one of the most promising candidates? Martin mentioned licensing: with a permissive license, we could fix any accessibility barriers ourselves. He and Jason mentioned this too: if the component has easy to use APIs and hooks for customisability, we can take matters into our own hands..

Wrapping up

To sum up: not all ‘accessible components’ are created equal, some will work a lot better for our end users than other. In this post I have listed a number of things you can look at if you are considering third-party components.

---

Originally posted as Accessible front-end components: claims vs reality on Hidde's blog.

Reply via email

In recent weeks, people have been publishing “typical day” posts. They have been fun to read. In what Ethan Marcotte aptly called a “blogging chain”, started by Colin Devroe, Michelle tagged me and some others. So, here it goes, some typical things about my daily life.

I’ve been admiring other people’s ability to wake up early, go for early-morning runs and/or have carefully carved out daily schedules. If you want to read what other people’s days look like, I liked those of Michelle, Matthias, Ethan , Cassie, Jeremy and Sara.

Days have been very different in the last six weeks, as I’ve taken most days off during the Dutch daycare lockdown. Those days were full of cooking together with the kids, long walks with the kids and, when it rained, painting loo rolls (again, with the kids). Super challenging, because how do you balance all that and a freelance business? Working with a baby on one arm and a toddler running around the room is a myth. It was also super rewarding, for all the obvious reasons: babies and toddlers can be immensely cute and lovely. We learn a lot from and about each other.

Below, you’ll find a description of a somewhat regular day. The times and activities can vary.

07.00-8.30

A combination of wake up, make breakfast and coffee. We get everyone dressed, read the morning paper. I read my morning paper physically. This was initially so that I could skip online news, but who am I kidding–even with most news sites blocked via my /etc/hosts, I can’t resist and go peek on my phone.

08.30-9.30

Walk kids to daycare. If I’m alone, this is usually my chance to listen to audiobooks or podcasts on the way back home, and take a longer route if time allows. Podcast-wise, I’m a sucker for long form interviews, like NTR Kunststof, Nooit meer slapen and Groenteman in de kast in Dutch, and James O’Brien’s Full Disclosure and Brené Brown’s Unlocking us in English.

09.30-13.30

This is where I try to get a lot of work done. I usually don’t have meetings, as my US counterparts are still asleep. I may be working on an accessibility audit or presentation slides, or, if it’s a W3C day, I may be coding accessibility conformance tooling, review surveys from the Education & Outreach Working Group or generate the WCAG XSLT over and over for our current redesign project. Usually I drink Taiwanese high mountain tea.

13.30-14.00

Lunch time! I extend it sometimes, especially if I have evening meetings, so that I can go outside and/or cook hot lunch.

14.00-17.00

This is usually a combination of meetings, 1:1s and getting work done. I may be doing some work on components for the WAI website, talk to CMS vendors for WAI-Guide or attempt to split up large amounts of work into GitHub issues. Some time into the global pandemic, I purchased a second hand hifi set and placed it inside my home office, so that I can listen to all the jazz, ambient, pop, rock and hiphop when not in meetings. I check the number of positive COVID tests, which is easier if it decreases.

17.00-19.30

Daycare pick up, cooking and eating. Depending on how smooth things went and how much time there still is, we also use food delivery. I get better at not feeling too guilty about that. After dinner we usually put on music and dance a bit. Sting and Shaggy, Chika, Gregory Porter, Nile Rodgers and Moby have been recent favourites. K3 and their song about washing hands and Juf Roos, too.

19.30-21.00

Trying to get the kids to sleep, read bed time stories, answer mesmerising questions about the universe and its workings. Also wash up and prepare baby food. Sometimes I have an evening meeting. On Thursdays I recently started attending Open UI telecons.

21.00-23.00

Oh, is it this late already? We may watch Mock the Week if there are new episodes, see how Ku explores Taiwan or how Waes visits Japan. Travel and food themed shows help remind there was a prepandemic world. They give me hope that some of it may come back. Sometimes there’s a book I can’t stop reading or a guest in one of the late night talk shows that I don’t want to miss. I go to bed with a book.

Wrapping up

So, this is what my days roughly look like. I don’t really have any useful productivity hacks, but feel that walking, reading, listening, cooking and (even) cleaning are some things that I’m pleased to have in my days.

I’d like to invite Zell Liew, Ana Rodrigues and Eric Bailey to join this chain to talk about their days, if they want to!

---

Reply via email