Some attributes in ARIA are boolean(-like). These attributes may seem a lot like boolean attributes in HTML, but there are some important differences to be aware of.

George Boole, the philosopher and mathematician who came up with a type of algebra that has just true and false as its variables

Boolean attributes in HTML

In HTML, some attributes are boolean attributes, which basically means they can be true or false. They are the case, or they are not the case. They compute to one, or they compute to zero. Examples of these attributes include checked, required, disabled and open.

Boolean attributes in HTML are true when they are present:

The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

(From: HTML, Common microsyntaxes, Boolean attributes)

So, if a checkbox is checked, it has the checked attribute, otherwise it does not. The attribute, when present, can have any value, like checked="checked", though the HTML spec explicitly says we should not use true or false as attribute values for boolean attributes:

The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

It would work though: the checked attribute works with any value, even checked="true" or checked="false" represents that the input is checked:

<!--  
  on first render, the following 
  checkboxes are in checked state 
-->
<input type="checkbox" checked="true" />
<input type="checkbox" checked="false" />
<input type="checkbox" checked="hello" />

 <!--  
  on first render, the following 
  checkboxes are not in checked state 
-->
<input type="checkbox" />

In some cases, browsers will help us manage the presence of these attributes. They don’t for checked, but they do for details/summary (the open attribute on the details element when its summary is expanded or collapsed). In other cases, the browser can’t manage presence or absence, like for the required attribute. Whether an element is set to required, is up to the author’s intention, the browser defaults to “not required”.

The attributes I discussed earlier are what specifications call ‘content attributes’, we write them in our markup. In JavaScript, we can also affect the truth value of these HTML attributes with so-called IDL attributes, for instance:

element.checked = true; // sets checked state to true
element.checked = 'checked'; // sets checked state to true
element.checked = 'foo'; // also sets checked state to true
element.checked = false; // sets checked state to false
element.checked = ''; // sets checked state to false

Boolean attributes in ARIA

In ARIA, there are also attributes that can be true or false, but their state is expressed differently. It is a different language than HTML, after all. HTML is the most common host for it, but ARIA can also be used in other languages, like XML and SVG.

As explained previously, HTML has the concept of boolean attributes. It also has the concept of keyword and enumerated attributes. These attributes can come with a fixed number of string values. When ARIA is used in HTML, we use these types of attributes. This means that when we say “boolean” in ARIA, we’re really talking about strings that happen to be use the words “true” or “false”.

According to the type mapping table in the WAI-ARIA 1.1 specification, there are three different attribute types in ARIA that explictly list ”true” and “false” as possible values:

• attributes that are “boolean”, which accept only "true" or "false" (eg aria-busy, aria-multiline, aria-readonly)
• attributes that accept "true", "false" and "undefined" (eg aria-hidden, aria-expanded, aria-grabbed, aria-selected)
• “tristate” attributes, which accept ”true”, "false" or "mixed" (eg aria-checked, aria-pressed)

That’s not all, as there are also properties with different and larger sets of possible values:

• aria-invalid (takes "grammar", "spelling", "false" and "true")
• aria-haspopup (takes "true", "false", "listbox", "menu", "tree", "grid" and "dialog")
• aria-current (takes "true", "false", "page", "step", "location", "date" and "time")

All of these fall into that “keyword and enumerated attributes” bracket, they take a nullable DOMString.

ARIA attributes can be set using setAttribute(). From ARIA 1.2, which is currently a “Candidate Recommendation Draft” (it’s like a Candidate Recommendation, but with significant updates made to it), ARIA attributes can be specified using IDL attributes, too, for instance:

element.ariaChecked = "true"; // sets `aria-checked` to true

Scott O’Hara wrote about this upcoming feature in his post New in ARIA 1.2: ARIA IDL attributes.

HTML vs ARIA booleans

So, for HTML boolean attributes it’s all about presence and absence, while in ARIA boolean attributes, the boolean state is expressed via "true" and "false" string values and there are bunch of attributes that take those strings and a couple more.

Some examples of these differences:

• The absence of the checked boolean attribute maps to aria-checked="false" (unless it was modified, that is… so this mapping only applies in the elements default state)
• The presence of the disabled attribute maps to aria-disabled="true"
• The presence of the open attribute on details maps the state of its summary to aria-expanded="true", the absence of it maps it to aria-expanded="false"

Summary

So, there are boolean attributes and keyword and enumerated attributes in HTML. When ARIA booleans are used in HTML, they are of the latter type. They take one of two keywords: "true" or "false". There are also ARIA attributes that take "true" and "false", but also other keywords in addition. Those may look like booleans at first sight, but are not. That’s all, thanks for reading!

---

Originally posted as Boolean attributes in HTML and ARIA: what's the difference? on Hidde's blog.

Reply via email

Some attributes in ARIA are boolean(-like). These attributes may seem a lot like boolean attributes in HTML, but there are some important differences to be aware of.

George Boole, the philosopher and mathematician who came up with a type of algebra that has just true and false as its variables

Boolean attributes in HTML

In HTML, some attributes are boolean attributes, which basically means they can be true or false. They’ll be the case, or not the case. Some examples: checked, required, disabled and open.

Boolean attributes in HTML are true when they are present:

The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

(From: HTML, Common microsyntaxes, Boolean attributes)

So, if a checkbox is checked, it has the checked attribute, otherwise it does not. The attribute, when present, can have any value, like checked="checked", though the HTML spec explicitly says we should not use true or false as attribute values for boolean attributes:

The values “true” and “false” are not allowed on boolean attributes. To represent a false value, the attribute has to be omitted altogether.

It would work though: the checked attribute works with any value, even checked="true" or checked="false" represents that the input is checked:

 <!--  
  on first render, the following 
  checkboxes are in checked state 
-->
<input type="checkbox" checked="true" />
<input type="checkbox" checked="false" />
<input type="checkbox" checked="hello" />

 <!--  
  on first render, the following 
  checkboxes are not in checked state 
-->
<input type="checkbox" />

In some cases, browsers will help us manage the presence of these attributes. They don’t for checked, but they do for details/summary (the open attribute on the details element when its summary is expanded or collapsed). In other cases, the browser can’t manage presence or absence, like for the required attribute. Whether an element is set to required, is up to the author’s intention, there are no browser defaults.

The attributes I discussed earlier are what specifications call ‘content attributes’, we write them in our markup. In JavaScript, we can also affect the truth value of these HTML attributes with so-called IDL attributes, for instance:

element.checked = true; // sets checked state to true
element.checked = 'checked'; // sets checked state to true
element.checked = 'foo'; // also sets checked state to true
element.checked = false; // sets checked state to false
element.checked = ''; // sets checked state to false

Boolean attributes in ARIA

In ARIA, there are also attributes that can be true or false, but their state is expressed differently. It is a different language than HTML, after all. HTML is the most common host for it, but ARIA can also be used in other languages, like XML and SVG.

As explained previously, HTML has the concept of boolean attributes. It also has the concept of keyword and enumerated attributes. These attributes can come with a fixed number of string values. When ARIA is used in HTML, we use these types of attributes. This means that when we say “boolean” in ARIA, we’re realling talking about strings that happen to be use the words “true” or “false”.

According to the type mapping table in the WAI-ARIA 1.1 specification, there are three different attribute types in ARIA that explictly list ”true” and “false” as possible values:

• attributes that are “boolean”, which accept only "true" or "false" (eg aria-busy and aria-multiline, aria-readonly)
• attributes that accept "true", "false" and "undefined" (eg aria-expanded, aria-grabbed, aria-selected)
• “tristate” attributes, which accept ”true”, "false" or "mixed" (eg aria-checked, aria-pressed)

That’s not all, as there are also properties with different and larger sets of possible values:

• aria-invalid (takes "grammar", "spelling", "false" and "true")
• aria-haspopup (takes "true", "false", "listbox", "menu", "tree", "grid" and "dialog")
• aria-current (takes "true", "false", "page", "step", "location", "date" and "time")

All of these fall into that “keyword and enumerated attributes” bracket.

ARIA attributes can be set using setAttribute(). From ARIA 1.2, which is currently a “Candidate Recommendation Draft” (it’s like a Candidate Recommendation, but with significant updates made to it), ARIA attributes can be specified using IDL attributes, too, for instance:

element.ariaChecked = "true"; // sets `aria-checked` to true

Scott O’Hara wrote about this in more detail about this upcoming feature in his recent post New in ARIA 1.2: ARIA IDL attributes.

HTML vs ARIA booleans

So, for HTML boolean attributes it’s all about presence and absence, while in ARIA boolean attributes, the boolean state is expressed via "true" and "false" string values and there are bunch of attributes that take those strings and a couple more.

Some examples of these differences:

• The absence of the checked boolean attribute maps to aria-checked="false" (unless it was modified, that is… so this mapping only applies in the elements default state)
• The presence of the disabled attribute maps to aria-disabled="true"
• The presence of the open attribute on details maps the state of its summary to aria-expanded="true", the absence of it maps it to aria-expanded="false"

Summary

So, there’s boolean attributes and keyword and enumerated attributes in HTML. Booleans in ARIA are of the latter type, so they work slightly differently than boolean attributes in HTML and take a number of keywords, sometimes many more than true and false, at which point they aren’t really booleans.

---

The post Boolean attributes in HTML and ARIA: what's the difference? was first posted on hiddedevries.nl blog | Reply via email

Mid February I will start a new job: I am excited to join the developer relations team at Sanity!

I had my last day at W3C in October (look, my cool URI didn’t change) and set out to be mostly away from work for a couple of months. I guess I’m not great at this, as, besides another school lockdown here, I got fairly busy with existing projects. I did some WCAG audits, workshops, conference talks and… interviewing. I wanted to make sure to find the right place and took the time to do it. Having been a contractor for over a decade, it was my first time doing interviews, eh, ever.

My work at WAI taught me to consider the web in terms of systems like authoring/developer tools and user agents, as they impact the web in some very specific ways. It became clear to me I wanted my next role to be at a company that is heavily involved in somehow making the web better through tools like that. Whatever a better web looks like… more accessible, more secure, more privacy-aware… I got to talk to a number of different companies working on browsers, design system tooling, browser add-ons, web standards and content management tools. I could write about the job hunting process, but Mu-An already did that brilliantly.

The Sanity developer relations team made a great impression. The company has a cool product that solves some important problems, a friendly community (plus focus on keeping it healthy), lots of ecosystem, aaaand… there could be lots of new ecosystem possibilities. Sanity’s Year in 2021 blog post has a lot more detail on what Sanity is up to.

For the next few weeks, I will be finishing my current accessibility consulting projects with the Dutch government and Mozilla, go on holiday and then, get this new chapter started!

---

The post Joining Sanity was first posted on hiddedevries.nl blog | Reply via email

Mid February I will start a new job: I am excited to join the developer relations team at Sanity!

I had my last day at W3C in October (look, my cool URI didn’t change) and set out to be mostly away from work for a couple of months. I guess I’m not great at this, as, besides another school lockdown here, I got fairly busy with existing projects. I did some WCAG audits, workshops, conference talks and… interviewing. I wanted to make sure to find the right place and took the time to do it. Having been a contractor for over a decade, it was my first time doing interviews, eh, ever.

My work at WAI taught me to consider the web in terms of systems like authoring/developer tools and user agents, as they impact the web in some very specific ways. It became clear to me I wanted my next role to be at a company that is heavily involved in somehow making the web better through tools like that. Whatever a better web looks like… more accessible, more secure, more privacy-aware… I got to talk to a number of different companies working on browsers, design system tooling, browser add-ons, web standards and content management tools. I could write about the job hunting process, but Mu-An already did that brilliantly.

The Sanity developer relations team made a great impression. The company has a cool product that solves some important problems, a friendly community (plus focus on keeping it healthy), lots of ecosystem, aaaand… there could be lots of new ecosystem possibilities. Sanity’s Year in 2021 blog post has a lot more detail on what Sanity is up to.

For the next few weeks, I will be finishing my current accessibility consulting projects with the Dutch government and Mozilla, go on holiday and then, get this new chapter started!

---

Originally posted as Joining Sanity on Hidde's blog.

Reply via email

Like ‘Web 2.0’, ‘web3’ is a marketing term. There is no versioning system for the web. There are also lots of exciting uses for the web and problems with it outside the realm of ‘web3’.

It’s the later half of the 2000s. People had been building websites and online services for a while. Suddenly, everyone started using the phrase ‘Web 2.0’. It didn’t have one one clear definition, like ‘carrot’ or ‘dentist’. It referred to a bunch of things at once. Websites with ‘user generated content’, users tagging their data, software as a service, async JavaScript, widgets and open (!) APIs that allowed for mashups: sites that displayed content from other sites. New companies had names with less vowels, like Tumblr and Flickr, and there was RSS on everything. ‘You’ was made TIME Person of the Year. I’ve been returning to some stuff from that time, and it’s been interesting.

Many of the things that fit the above description of ‘Web 2.0’ were useful, they often still are on today’s web. We lost some, we kept some. But if we’re fair, ‘Web 2.0’ wasn’t some new iteration, a new version of something that was different before. It was largely reuse of existing web tech, like HTTP and XML. Exciting reuse, for sure. But a lot of it already existed in non-commerical forms before the phrase ‘Web 2.0’. Not everyone knows, but the first web browser, WorldWideWeb, was meant to be both viewer and editor. That’s quite ‘user generated’, I would say. So, what did Web 2.0 mean? ‘Web 2.0 is, of course, a piece of jargon, nobody even knows what it means’, Sir Tim Berners-Lee commented in an interview with IBM at the time.

Like ‘Web 2.0’, ‘web3’, and I’m not sure what’s with the removed space and dot, or the lowercase ‘w’, is just a marketing phrase. Definitions of ‘web3’ seem to be all over the place. From what I gathered, it is a vision of a web that runs largely on the blockchain, in order to make ‘owning’ assets better for people who create them and people who purchase them, by cutting out middlemen. This vision is not to be confused with the Semantic Web, which was also called Web 3.0, and discussed years before (see an article from 2006).

Here’s the thing. There is no institution that regularly releases new versions of the web, and recently happily announced this one. Instead, the phrase ‘web3’ was coined in 2014 by a co-inventor of a blockchain technology and since used by crypto asset enthusiasts and certain venture capitalist firms, for what is, some argue, close to ponzi schemes and, in its current form, very environment unfriendly. It also puts vulnerable people at risk (see Molly White ‘s web3 is going great for examples of those claims).

I’ll keep my issues with ‘web3’ for a later post, for now I just wanted to make the point that it’s unfair to claim a version number for the web for a specific set of innovations you happen to like. There are many ways the web evolves. Sometimes they involve the kinds of technology that ‘web3’ adepts use, but usually they don’t. These are some web innovations I like:

• New standards are written to harmonise how web tech works and invent new tech responsibly and across user agents, like CSS Grid Layout, WebAssembly and map/filter/reduce in JavaScript
• New companies start useful services, like payment integration services and ‘content as data’ headless CMSes
• Individuals start blogging on their personal sites, on which they own their content
• Governments and organisations roll out reliable, useful and accessible authentication services (like DigiD)
• Video conferencing companies bring their software to the browser
• Adobe brought Photoshop to the browser
• A couple of Dutch museums put all their entire catalogue of art online (eg Rijksmuseum, Stedelijk and Van Gogh Museum)

Maybe that list is a bit random, you probably have a list of your own. Many of these things are working just fine. I could personally go on and on about some very useful plans for the web. There are also lots of unsolved problems, like lack of web accessibility or Facebook’s business model. Cool things are planned for the web all the time and there are lots of problems that aren’t yet addressed. Most of the web is fine. At the same time, there are also plans and problems. Frankly, I don’t think we should use version numbers just to market a specific subset of plans and problems for the web. Especially not if that’s such a controversial subset.

---

The post The web doesn’t have version numbers was first posted on hiddedevries.nl blog | Reply via email