Category: HTML5

Categories
HTML5 Specs

The HTML5 longdesc attribute is finally home again

My HTML5 logo

I found out that the W3C had transitioned the HTML5 attribute @longdesc to Candidate Recommendation (CR) status from a tweet by John Foliot:

Yes, I believe I do owe John a beer. I owe a beer to all of those who fought to ensure @longdesc made it to CR—especially Laura Carlson, who worked so diligently on behalf of this attribute, and other HTML5 accessibility features.

Years ago I was heavily involved in the W3C HTML5 effort, though I was frequently at odds with Ian Hickson, HTML5’s sole editor at the time, and some of the Working Group’s management. Since then, the W3C has transitioned the care and management of HTML back into a group effort, leading to decisions such as giving @longdesc CR status.

I don’t agree with all W3C decisions, but my main concern has always been that the decisions reflect a representation of those who support or depend on the web—not just an elite few. The transition of @longdesc to CR status demonstrates that the HTML5 working process has, indeed, grown up.

Well done.

Categories
HTML5 Standards XHTML/HTML

Letting go of the passion can be a good thing

For years I battled with members of the WhatWG and others over elements and attributes in HTML. Months, we’d go back and forth about the usefulness of the details element, or in passionate defense of the beleaguered longdesc.

I wrote hundreds of pages in defense of RDF over Microdata; the virtues of SVG in addition to Canvas; and what the hell does it really mean when we talk about web accessibility?

But I lost a lot of the interest in fighting over markup about the same time it seemed most of us became burned out on the never ending debates. I dived into the exciting possibilities of Node.js, while also exploring, more deeply, the world outside of technology. My interests were split between JavaScript and circus elephants, web technologies and sustainable food systems. Along the way, I lost the passion I felt about finding the one true way for forward movement of the web. The technologies are still important to me, yes, but I had lost the pounding insistence of rightness I felt about individual components, and even entire systems. And once the noise in my own head seemed to quiet, I could hear others—their passion, their sense of what’s right.

The real epiphany came when I was reviewing Kurt Cagle’s upcoming book, “HTML5 Graphics with SVG and CSS3”. In the book, Kurt has a chapter on HTML5 where he demonstrated an unconventional HTML web page that blasted apart all I thought I knew about what is a proper web page. It did so because as chaotic seeming as it is, it’s still a valid web page. I couldn’t see the validity of the page, though, because I had been rigidly holding on to a perspective about HTML that really was over, done with, gone.

Never to return.

I had been seeing the web through XHTML colored glasses. In the past, I had been trying to map the precision and order that exemplifies XHTML with the loose but more nuanced flow that is HTML5, and there really is no philosophical compatibility between the two. Kurt’s example forced me to see HTML5 it all its raw essence, for lack of a better word. And what blows me away is realizing that browser companies, as well as many web developers, designers, and folks interested in accessibility prefer HTML5, even at its messiest, over the ordered world of XHTML. They do so not because they embrace chaos, but because they saw something in the future of HTML I didn’t.

I don’t seek a second epiphany that would allow me to view the web through their eyes. My passions have gone elsewhere. In the world of technology, my focus now is on JavaScript and Node, and all the new adventures that seem to be exploding about both. HTML is complimentary to my interests, but not central. It is now nothing more than a tool; essential to developing with JavaScript and in ensuring accessibility of my published words, yes, but still just a tool.

HTML is a passion for others, though, and I respect that passion because I respect them. If the people I respect assure me, knowledgeably and with conviction, that using certain elements in a certain way will ensure my web pages are accessible for all across a variety of mediums, I will pay attention. When next I take on the grand redesign of my web sites (typically an itch I must scratch on average every three to four years), I will modify my pages accordingly. I do so not because I believe in the technology, but because I believe in the people.

Categories
Diversity HTML5

Homogeneity

homogeneity: noun

composition from like parts, elements, or characteristics

Not long ago, Molly Holzschlag tweeted an innocuous comment:

I’d love to see a woman or group of women edit the HTML5 spec. It’d make for an interesting social experiment. Certainly would be a first.

I re-tweeted her without additional comment, and that started a sequence of responses that surprised me in their vehement rejection of “positive discrimination”—as if the only way that women could possibly be involved in editing the HTML5 spec is because of the result of some kind of reverse discrimination.

Craig Grannel caught the byplay and sent me an email asking if I’d be willing to be interviewed for .net magazine, not only about the tweets, but comments I made about the W3C and sexism. Discussions on this topic have not gone well in the past, and I didn’t expect any positive dialog from this interview, but as the saying goes: hope springs eternal.

The interview appeared in Call for greater diversity in web community. I thought that Craig did a decent job of taking my disjointed thoughts and punching them into a coherent whole, but I also decided to publish my full comments. There were a couple of points I made in my response that I wanted to emphasize.

> – How do you think the HTML WG would benefit from female leadership, or, at least, more women being involved? In what ways do you think the “dynamics of an all male leadership” have been negative?

I can’t give you a sound bite, because there is a back story to these communications. I guess I’ll have to trust that what I write will either not be used, or won’t be used in such a way as to cause more problems.

Women are underrepresented in the tech field, but they’re even more underrepresented in W3C working groups. Even with the recent addition of a woman to the TAG group, men in leadership positions in the W3C and in W3C working groups is disproportionate.

Unfortunately, women also underrepresented among the W3C representatives from the browser companies, which is why I believe the HTML WG is so badly skewed towards the masculine.

The group’s entire focus the last few years has been on basically giving the WhatWG members representing a few of the browser companies whatever they want. The procedures put in place to demonstrate a more “egalitarian” viewpoint have actually done the opposite.

If you’ve followed along the effort over the years, the debacle over the longdesc attribute, an accessibility aid, is representative of how badly the change process procedures have failed.

And that might be one key to some of the problems women have had in the group. Most of the women participating in the HTML WG have come in from the accessibility movement, and the people interested in accessibility have long been recipients of disdain and derision–typically expressed outside the group, true, but impacting on group dynamics.

However, what happens in public concerns me less than what happens in private. I’m not the only woman who has received a “tsk tsk, must behave better” email from the HTML WG chairs and members. The chairs say they’ve sent emails of like nature to guys, too, but there’s a different flavor to the communications–a patronizing tone that just sets my teeth on edge.

One time, I addressed some of my concerns in an email to www-archives–the dump hole for W3C communications–about my perceptions of sexism in the HTML WG group, and a W3C staff member wrote me to chastise–literally chastise me–telling me that he showed the communications that led to my emails to his girlfriend. and she didn’t see anything sexist about them.

As if we women all think alike, like some kind of single celled organism that shows absolutely no differentiation.

Tell me something: do you think the exact same thing as all the men you know? Do you perceive writings the same way? Do you all share the exact same opinions? Then why the heck would any of you expect the same from women?

I actually did formally complain to W3C leadership about my concerns about the HTML WG and underlying, subtle sexism, and their handling of the complaint was appalling. They turned around and communicated my complaint to the HTML WG co-chairs, one of whom sent me a blistering email in response. It was impossible to work with the group after that, and I’ve had little respect for the W3C management since.

Now I’m greatly concerned, because I’m seeing the same disdain and patronizing attitude directed to an HTML WG member who has been with the group for years, fighting for accessibility. I’ve watched her become disillusioned, and go from being an active, engaged member, to someone who rarely participates at all.

It’s not right.

Can more women in leadership help? I honestly can’t say whether we could or not, but I’d like to think it would help to have more women in positions of responsibility and authority. At a minimum, we couldn’t make it any worse that what it is. Frankly, the group is too homogeneous. It really doesn’t represent the broader Web community.

> – You said: “How about encouraging more women to get involved, rather than chasing out most who were?” What did you mean by that? (Note: from some of the responses in your feed, I can certainly infer, but it’d be good to get your thinking on this.)

I don’t want to speak for other women, I can only speak for myself.

I left the HTML WG group. I just couldn’t handle the emails telling me to behave, the chastisement, as if I’m a little girl and they’re all Daddy. I have better things to do with my time than be condescended to.

What’s been frustrating about my decision to leave, though, is people telling me now that “If you don’t like what’s happening with HTML5, get involved”, when I was involved at one time, and had to leave.

What’s even more frustrating is an attitude I see from many men and women involved in technology, especially as it relates to the W3C: unless a guy points out that sexism exists, it doesn’t exist.

Sexism isn’t always overt. It isn’t always some guy showing a slide with a naked woman’s bum during a tech conference. Sexism can be as much slow erosion as sudden explosion. Women feeling as if we’re ignored, that we’re patronized, that our contributions weigh less–sexism is as much about subtle perception, as it is about blatant acts.

In my opinion, the W3C, in general, and the HTML WG, in particular, have problems with sexism.

And every time I say this, I get slammed. So here we go again.

Ian Devlin wrote what I felt was a disappointing response to the .net magazine article.

What I did have issue with however, was what I saw as the implied notion that a woman would be better at doing the job of HTML5 editor simply because of her sex.

Isn’t that just as bad as saying that a man would be better at the task at hand simply because he is a man? Such a comment would, quite correctly, cause uproar. Granted the implication probably wasn’t intended, but I think that it was this perceived attitude that started the debate.

No one ever implied that women would do better just because we’re women. This was never said: in Molly’s comment, in my responses, or in the article. The real focus in all of the remarks was on the lack of diversity in the W3C leadership and among the working groups. Not only are women not well represented, but even among the men there is little diversity. Those who have defined the HTML5 spec display a remarkable similarity in thought and opinion, matched only by an almost complete lack of empathy.

Could women help? Good lord, we couldn’t make matters worse.

There’s a second component to my comments, though, that I wanted to re-emphasize: that sexism isn’t always overt acts. In fact, I don’t really care about overt sexism. Acts of this nature tend to self-implode, and they don’t need me to light a match. No, it’s the subtle form of sexism that bothers me. As I wrote in the interview response, subtle forms of sexism erode over time. There is rarely anything anyone can point to and say, “Aha! Sexism!” But in the back of your mind, there exists a feeling that no matter what you do or say, you won’t be heard, your concerns will not be addressed, your input really isn’t welcome.

You just kind of drift away.

Even now, when we have a fresh opportunity to discuss the issues, to address the lack of diversity in the W3C, our concerns are rejected as “positive discrimination”. That’s the same as saying how dare we hit that fist with our face.

Just as an aside: I did volunteer to be a co-editor of HTML5, back in 2008, I believe it was. My offer was rejected.

Categories
HTML5

If it had remained the irrelevant attribute

Recovered from the Wayback Machine.

The latest round of discussions related to longdesc (yes, still) was triggered by a revert request from Laura Carlson:

As you know the editor made changes to the hidden section [1]. This biases an open issue [2] as it directly implements a material change from a change proposal [3]. The Chairs specifically asked for justification for this change in their change proposal review [4]. If the proposal lacks justification, then the spec lacks justification.

The change redefined the meaning for the hidden attribute, from:

When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have the hidden attribute specified.
…
Elements that are not hidden should not link to or refer to elements that are hidden.
…

It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.

To:

When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page’s current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that have the hidden attribute specified.
…
Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.
…
It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. While hiding the descriptions implies that they are not useful alone, they could be written in such a way that they are useful in the specific context of being referenced from the images that they describe.

Similarly, a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.

The change significantly redefines the meaning for the hidden attribute. Why did the editor make this change? One reason was, as Laura pointed out, bolstering a change proposal to obsolete longdesc in favor of a proposal to use aria-describedby pointing to a section marked by the hidden attribute.

This triggered two separate discussions—one related to making an edit to HTML5 specifically in favor of a change proposal currently under rather contentious debate; the second related to redefining hidden in such a way that aria-describedby would be allowed to point to it.

The revert request was successful, which now leaves the discussion about allowing aria-describedby to point to content marked with the hidden attribute, and this change’s impact, or not, on the decision to deprecate longdesc. I’m not going to get into the longdesc deprecate debate—my views on this are widely known and I’ve long been in support of keeping this attribute in the HTML spec. Instead, I want to focus on the change to hidden.

A recent post to the HTML-WG mentioned separating the aria-describedby/hidden issue into a separate survey (and there’s now an issue for it). However, I wanted to remind the HTML-WG co-chairs that they already decided this issue back in 2010.

In 2010 I made a request to remove the hidden attribute from HTML5. In the change proposal to support the request, I wrote:

The hidden attribute was once named the irrelevant attribute, supposedly because the attribute is used to mark the contents of whatever element it is attached as “irrelevant”. The attribute was renamed because, a) the irrelevant term was confusing, and b) techs misspell words like “irrelevant”.

Is the content truly irrelevant, though? Consider the definition for the attribute:

Elements in a section hidden by the hidden attribute are still active, e.g. scripts and form controls in such sections still execute and submit respectively. Only their presentation to the user changes.

“An irrelevant element is not one that is active, receiving events, participating in the web page, or form submission. The only truly irrelevant page component is one that doesn’t exist. If people want a truly irrelevant page section, they should use the DOM to create and remove the element, as needed. There is nothing about the behavior associated with removing an element from user agent rendering that is made more meaningful using a single-purposed HTML attribute, rather than using a simple combination of CSS property and ARIA attribute. Both have to do with the presentation of the element.”

Presentation with the hidden attribute isn’t an incidental purpose, it is the primary purpose of the attribute. Rather than separate presentation and structure, it firmly welds the two.

My request to remove hidden wasn’t successful, based on the strength of arguments in favor. What were these arguments? The following is the primary one, from the counter-proposal:

Authors of web documents and applications often need to temporarily hide certain content from readers and users. Via a combination of script and CSS, such functionality is possible to build today, and there are hundreds of such implementations extant on the web. It’s clear that hidden=”” Solves Real Problems. Attempting to implement such functionality with JavaScript and CSS is fundamentally more difficult and error-prone than hidden=””. hidden=”” is literally the simplest thing that could possibly work, and thus we Avoid Needless Complexity in its design. By making it as easy as possible to author, and by defining uniform UA behavior (unlike bolt-on scripts which emulate this functionality), we preserve our Priority of Constituencies. Bolt-on emulations of hidden=”” can fail to correctly hide content in a media-independent way, resulting in a degraded experience for users of aural browsers and other AT tools. hidden=”” thus promotes Accessibility more than bolt-on alternatives.

In the survey deciding the issue of keeping hidden or not, several arguments in support of keeping hidden were given.

Cynthia Shelly wrote:

The existing mechanisms all miss one case or another, and it is complicated to understand when to use one over another. The new hidden attribute covers all the cases in a way that will make it much simpler to include markup on a page that is intended as input to a script rather than output to a user.

Gregory Rosmaita wrote:

a native solution which provides the means of marking content as not yet or no longer relevant, is highly desireable; while such a feature, of course, needs to be harmonized with what ARIA offers, it MUST be remembered that aria-hidden is part of a bridging vocabulary, which provides semantics and functionalities which native markup does not provide; the hiding and exposition of content that is not yet, or is no longer, relevant should not be left to scripting or an overlay such as ARIA, but should be an organic part of HTML5.

Jonas Sicking wrote:

I object to removing the hidden attribute as it would result in missing out of the positive effects listed in http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements#Positive_…

My experience working with web authors for several years is that they tend to do what is easy, whereas accessibility often ends up coming second due to time constraints and unawareness.

By including the semantic hidden element, we both make it easier for developers to do what they want, since they can use the .hidden IDL attribute, and they automatically get the desired semantic meaning.

I think it’s very unlikely that as many people would add proper ARIA attributes, as would use the hidden attribute. I think this is the reason that the WAI-ARIA specification encourages developers of markup languages to add semantic elements and explicitly declares ARIA as a bridge technology. I also think this is why the HTML Accessibility TF has endorsed the hidden attribute.

Among the arguments was the assertion that the hidden attribute is equivalent to aria-hidden, but better because the hidden attribute was integrated into the HTML semantics, rather than be “bolted on” via ARIA. Since aria-hidden is used specifically to designate material that is not perceivable to any user, this adds weight to the interpretation of content that is marked as hidden is content that is irrelevant to all users—at least until such time the hidden attribute is removed (equivalent to setting aria-hidden to “false”).

The co-chairs agreed with those who argued in favor of keeping hidden, writing:

It seems that the hidden attribute serves a valid, broad use case. It has interest from implementors and authors.

A number of arguments were made in favor of retaining the hidden attribute. It was argued with partial success that hidden captures useful semantics. Many cited the accessibility benefits of built-in elements and attributes, including hidden. A number of other concrete benefits were cited, such as likelihood of surviving syndication. These positive arguments were in general stronger than the counter-arguments, and provided strong reasons to keep hidden.

There were also arguments made against the hidden attribute. It was argued that CSS+ARIA-based implementations of hidden-like functionality are sufficient, so no attribute is needed. Deployment costs were also cited as a concern. And the semantic nature of the attribute was cast in doubt. In general, these arguments did not overcome the counter-arguments, and are not strong reasons to remove hidden.

The maturity argument against hidden had more weight. The Working Group has in the past chosen to remove features from the draft for reasons of maturity. However, this factor was not decisive in itself, at least at this time, since the W3C Process allows further opportunities for review, implementation and feedback.

Overall, the arguments in favor of keeping hidden were stronger than the arguments for removing it. Only the maturity argument provided a strong reason for removal, and it is outweighed by the arguments in favor of keeping it.

In my opinion, the decision was not necessarily a model of clarity. However, I do believe that this 2010 decision answers the question whether aria-describedby can point to an element marked with the hidden attribute, and the answer is, No.

An attribute used to designate content that is available for scripting purposes is not the same as an attribute that is used to remove the content from visual display. Why? because one implies the same result regardless of type of browser accessing the page, while the other implies something completely the opposite.

My understanding of the decision in 2010 is that “hidden” meant that the material was irrelevant regardless of type of browser accessing the page. This is supported by the fact that at one point in time, the hidden attribute was named irrelevant. The reason the name of the attribute was changed was more one of expediency than change of semantics. The visibility of the content should make no difference on whether it is relevant or not.

As the HTML5 editor, Ian Hickson, wrote when he renamed irrelevant to hidden:

It’s not different from hiding content that isn’t necessary. That’s exactly what it is. It’s a way to hide content that isn’t currently relevant.

I challenged the hidden attribute years ago because it seemed to me it was nothing more than an elemental equivalent of display: none. However, others, including the co-chairs, disagreed with me, and agreed with the HTML5 editor: the hidden attribute had the additional semantics related to its irrelevancy.

Based on this decision two years ago, I’m at a loss to understand why the HTML5 co-chairs would consider an option to allow aria-describedby to link to this content so that it can be rendered by screen readers—in effect, to make the content in the element with the hidden attribute, relevant. Something cannot be both relevant and irrelevant at the exact same time.

Categories
HTML5 W3C

This week in HTML5 in verse

This week in HTML5…in verse.

So <time> is saved
though it may be changed,
and <data> is on the horizon.

<hgroup> is going,
you can hear it moaning,
as HTML5 continues to wizen.