This week, a friend shared a blog post that critiqued a popular framework for CSS. Twitter started to discuss if it’s okay to criticise tools. In this post, I’ll say it is not just okay, it is also important.

I was a little disappointed to see the replies to this tweet. Among the many replies, the person who came up with the framework exclaimed seeing the post shared by her “ruined” his day. Note: the post was not about him, it was about the framework (the one that, on its homepage, criticises other people’s CSS methodologies) . Other commenters said the article was “not worth sharing”, “you’re just starting of fights” and “why would you amplify that?”.

I’m not interested in attacking anyone here, or going into the merits or faults of The Post, but would like to answer that last question. Or, in fact, a more generic one: “is it okay to criticise tools?”

Listening helps

The short answer is: yes. As long as it is aimed at the tool, not the person that created it, it is better to share criticisms than not. I have never been involved in the development of frameworks for the web, but in standards for the web, like HTML, CSS and ARIA, there is lots of criticism. People poke holes in each other’s assumptions, suggest ways to make features better and explain why things don’t work well for them. Good standards require diverse perspectives.

Again, the kind of criticism I’m talking about here is criticism of the content, not a person. Is some proposal vague? Should we really call that property “left justify” or number-form seems counterintuitive as a property name–just two examples of critiques of the first version of CSS, in 1995. They’ve made CSS better, because we’ve ended up with better names. Thanks to the people who took the time to send in comments. This is, for over 25 years, how we’ve evolved the web: by listening to each other and not taking critical comments personal.

Can we “just not use it”?

Maybe web standards like CSS are different. The web is built on it and you cannot not use CSS when you build a website. Browsers have stylesheets. But if we’re honest, the most popular tools and frameworks also impact all of us. Most web developers don’t always get to choose their own tools and frameworks, they join a team with existing code or have team members with other opinions.

I’ve never included Bootstrap in a project myself, but have contributed code to many projects that did. Just like it is helpful to comment on web standards, it is helpful to comment on tools and frameworks, because they too affect us all. This goes both for whether to use the thing at all, and for features the thing has or lacks.

Like critical thinking pushes the world of ideas forward, I mean in philosophy, criticism of ideas for standards, tools and frameworks pushes the web forward. We should give feedback respectfully and constructively, but we should give feedback. And open up to feedback, not demand it to go away. It may not be easy, but it is important to include perspectives outside your own.

---

Originally posted as Criticism pushes the web forward on Hidde's blog.

Reply via email

I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?

‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).

For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.

The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.

As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.

What’s normative in WCAG

The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.

What’s not normative in WCAG

Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).

There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).

For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.

The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.

The norm is the core

In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.

That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!

Conclusion

In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.

---

The post What's ‘normative’ in WCAG? was first posted on hiddedevries.nl blog | Reply via email

I’m currently involved in a project to make some of the WCAG guidance more clear. One of the distinctions we’re hoping to clarify is: what’s normative in WCAG?

‘Normative’, meaning something like ‘required to meet the norm’, is a common phrase in (web) specifications. You’ll find it in WCAG, but also in HTML, CSS and many others. Specifications say what we should do (‘do X’), in a way that can be evaluated afterwards (‘was X done?’).

For instance, the normative sentence ‘Web pages have titles that describe topic or purpose’ (from: Page titled) can be evaluated: if a web page has a title and it describes topic or purpose, it’s a pass. Otherwise, it’s a fail.

The opposite of ‘normative’ is ‘informative’, it is something that is not required for conformance to the norm. You may also find it is called ‘non-normative’, ‘not required’ or descriptive in some places.

As an aside, the words ‘may’, ‘must’, ‘must not’, ‘not recommended’, ‘recommended’, ‘should’ and ‘should not’ have special meaning in the context of specifications like WCAG. This meaning is defined in a document called RFC 2119.

What’s normative in WCAG

The part of WCAG that is normative is the main WCAG text itself: the Principles, the Guidelines and the Success Criteria.

What’s not normative in WCAG

Some of the WCAG text is not normative, like the Introduction section. It is marked as such (“This section is non-normative”).

There is also a number of documents to help use WCAG, including Techniques and Understanding documents. These documents are not normative either. They are additional information, context and examples, but not requirements to meet the norm (see 5.1, Interpreting Normative Requirements).

For instance, if you would evaluate whether a website meets the WCAG criteria, what matters for conformance is the text of the relevant criterion. The text in a Technique or Understanding document can help understand the intents and purposes of the norm, but it is not the norm. You don’t need to follow any specific Technique to be conformant.

The same goes for pages like ARIA Authoring Practices Guide, which is a Working Group Note. For more info on different kinds of see also Documents published at W3C.

The norm is the core

In most standards, the part that has become the norm was discussed and tweaked by many people over an extended time. Working Groups often spend years ensuring a wide variety of people was consulted and many views heard. There are likely many other things that could have made it in, but this was the text on which the Working Group reached consensus: it was supported by a substantial part of the group, and no formal objection was registered.

That leads me to an important point regarding WCAG: the normative part is the minimum to make your site work for users with disabilities. There are lots of best practices outside WCAG scope that benefit actual people–absolutely do find and use those!

Conclusion

In WCAG, the main text is normative, which means it is required to meet the standard. Other texts like Techniques, Understanding documents and ARIA Authoring Practices are not, they provide useful context, examples, background information and more.

---

Originally posted as What's ‘normative’ in WCAG? on Hidde's 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?

---

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