Apps optimize

HTML 5 Editor Ian Hickson discusses features, pain points, adoption rate, and more

Justin James, who is now a member of the HTML Working Group, interviews HTML 5 Editor Ian Hickson. Discover the pain points Hickson expects HTML 5 will address, his favorite features, the features he thinks might be most contentious, and much more.

 

In January 2008, I wrote that HTML 5 was headed for a change of course... straight for the iceberg. In response to my highly critical comments, Ian Hickson, the editor of the HTML 5 specification, let me know that I was more than welcome to join the HTML Working Group. In the spirit of trying to be helpful, as well as giving something back to the development community, I decided to join the group.

It has been interesting to be involved in the standards process. While Ian and I have had our disagreements over a few details of the specification, I have come to respect him immensely for the work that he puts into the spec on a daily basis.

Since there was such a large response to my initial post on HTML 5, I thought that TechRepublic members would be interested in getting a sneak peek of what to expect in HTML 5, as well as a look into the history of HTML 5, the standards writing process, and what it is like to be a part of it. I asked Ian if he would be interested in participating in an e-mail Q&A, and he graciously accepted.

Note: This interview is also available as a TechRepublic download. It's been nearly 10 years since HTML 4 was published as a spec, about the same amount of time that it took to get to HTML 4. How do you think that this timeline affects HTML 5?

Standards development isn't like making software -- people are implementing HTML5 as we speak, and many parts of HTML5 will likely be widely used long before HTML5 is officially "done." There are many parts of HTML5, like the canvas element and the postMessage mechanism, that are already implemented in multiple browsers.

Bearing that in mind, timelines for specifications are often a point of contention. Back when the W3C asked for feedback on the HTML working group charter, in November 2006, I suggested the following timeline, taking into account that work on HTML5 started in late 2003:

  • First W3C Working Draft in October 2007.
  • Last Call Working Draft in October 2009.
  • Call for contributions for the test suite in 2011.
  • Candidate Recommendation in 2012.
  • First draft of test suite in 2012.
  • Second draft of test suite in 2015.
  • Final version of test suite in 2019.
  • Reissued Last Call Working Draft in 2020.
  • Proposed Recommendation in 2022.

This may look ridiculous (2003 to 2022 is 19 years!), but it's worth considering how this compares to HTML4, DOM2 HTML, and XHTML1, the three specifications that HTML5 is intended to update and replace.

Work on HTML4 started in early 1997. The specification itself took about 2 and a half years, and was published in late 1999. Work on XHTML started while this was happening, in 1998, and it was officially completed in 2000.

The HTML DOM specifications were done by a completely separate working group: DOM1 started in 1997 and was published in 1998; work on DOM2 HTML started shortly after in late 1998 and was completed in 2003. So, generously, the spec editing work spanned from 1997 to 2003, a period of 6 years or so, the same amount of time as 2003 to 2009, which is what the timeline above predicts for HTML5 to reach "last call."

However, HTML4 and DOM2 HTML were very vague specifications, leaving many things completely undefined, in particular error handling. HTML5, in addition to specifying many new features and specifying the rules for many features that were hitherto unspecified (like the Window object or how to parse HTML!), also specifies, in detail, the inner workings of all these features, along with how to handle all possible errors. This is a significantly more comprehensive effort. That's what the three extra years (from the "last call" in 2009 to the "candidate recommendation" in 2012) are about: We're expecting a lot of comments beyond the thousands of comments we've already received, and it will take time to deal with them.

We're also fully intending to do something that none of the aforementioned specs really did, which is to have a comprehensive test suite that we will require at least two browsers to completely pass before we call it a day.

If one were to try to write such a test suite for HTML4 and DOM2 HTML, one would find that there isn't even one browser that fully implements those specifications, let alone two. We want to have such a high bar with HTML5 to avoid falling into the trap of saying "ok the specification is done" before we can actually prove that it is possible to implement HTML5 as written. There are things in HTML4 and DOM2 HTML that simply will never be implemented as written by browsers, for example, because implementing the feature as written would mean not rendering existing Web pages as the authors expected. If we find such problems in HTML5, we'll change the specification -- but to find such problems, we have to write big test suites and that's going to take a long time. That's what the last 10 years of the timetable are about.

One of my favorite new items in HTML 5 are the <audio> and <video> tags, since it relieves HTML authors from having to deal with Flash, <object>, <embed>, etc. What other pain points do you expect HTML 5 to address?

I expect the iframe sandboxing feature will be a big boon to developers if it takes off. My own personal favorite feature is probably the Web Sockets API, which allows two-way communication with a server so that you can implement games, chatting, remote controls, and so forth.

A lot of the real pain that HTML5 addresses though is in things that are much harder to point out. For example, we now define exactly how an HTML document must be parsed, whether it is full of errors or not, so forgetting a closing end tag will no longer mean four different browsers do four different things. Similarly, we're defining exactly how all the little APIs like window.history and location.href and setTimeout() work -- APIs that everyone uses without thinking about but which have never been defined before HTML5. By having a strict definition of how these APIs have to work, we're going to be able to get rid of a lot of weird browser bugs that have plagued authors for years.

What do you think will be the most contentious changes in HTML 5?

HTML5 defines sort-of-new meanings for the b, i, and small elements, which I thought would be really contentious, but really only a few people complained.

The things that ended up being the most contentious were things I didn't really expect. At one point, I added a paragraph in the spec that said that we were looking for a royalty-free, patent-unencumbered, and low-submarine-patent-risk video codec, and we received a record number of e-mails on the topic overnight, as every news site on the Web seemed to take this as a sign of the apocalypse.

Another topic that's received a lot of feedback is that we dropped acronym in favor of just using abbr, and a lot of people complained, though few could agree on what exactly the two elements would mean if we kept both.

More recently, there have been two big topics, both on what I consider to be remarkably unimportant parts of HTML, all things considered. The first was with the img element and its alt attribute. HTML4 requires alt but doesn't give any advice about how to use it. With HTML5, I added a long section that describes how to use it in detail and said that in some cases (e.g., webcams), there might not be any useful replacement text, and so it would be ok in those cases (and only those cases) to omit the attribute. This caused a firestorm of protest from so-called accessibility experts. There were even some people arguing that Flickr (another site that today shows images but doesn't always have suitable alternative text) should require photographers to always include detailed descriptions of every image they upload.

I tried to mitigate some of these arguments by requiring the alt attribute but allowing a special syntax to be used to say that there was no available replacement text, but that hasn't proved popular either, and it has its own problems. It's unclear exactly what we'll do, but personally, I'm leaning towards going back to the first proposal, which was at least simpler, if not ideal.

The second big controversy in recent history was over extensibility. There have been some requests to allow people to extend HTML without speaking to the committees working on HTML. We've provided a number of mechanisms for this (the class and rel attributes, the data-* attributes, the meta element for page-wide metadata, the script element for non-script data blobs, the embed element for plugins), but some people simply want the ability to invent their own elements and tag names. So far, we've managed to avoid that, and we'll have to see if we can continue.

Despite being a spec for nearly 10 years, many Web sites still do not validate against HTML 4, or are still using obsolete tags. Do you think that the adoption rate of HTML 5 will be higher than HTML 4?

Yes and no. I don't think we'll see a change in the fraction of pages that are conforming. I did a study using the resources Google provides me with and, in a sample of several billion documents, something like 90% of them had a syntax error of some kind -- and that's not even looking at whether they were nesting the right elements in each other or not. We have made some changes in HTML5 to make the syntax a little easier. For example, we now have allowed the "/>" talisman that XML introduced, and we've allowed IDs and class names to contain any character, since those restrictions weren't really helping anyone. But other than such superficial changes, I don't think that realistically speaking HTML5 is going to make people write better markup.

As to adoption, assuming we only consider adoption of the truly new features that HTML5 has introduced, then it will depend on where you look.

Blogs will probably use the new elements within a few years, as templates are updated and browsers start supporting the new elements -- instead of lots of div elements with classes, people will be able to use elements like article, footer, and so forth. Web applications will also be big users of new HTML5 features -- in fact, originally the HTML 5 specification was called "Web Applications 1.0" because it focused primarily on introducing features for Web Applications like Yahoo! Mail or Google Calendar. An average page that is talking about medieval beekeeping, however, probably won't have much use for many of the new HTML5 features, and it'll be hard to say if authors of such pages are really "adopting" HTML5 or not.

To be honest, though, I don't think it matters. HTML5 has already been enough of a success in bringing browser vendors together and addressing the many problems in HTML4 (like the lack of parsing rules for invalid documents) that whatever happens next, it was worth it so far.

The HTML 5 spec is aimed at a number of different groups: browser vendors, HTML authors, developers of HTML authoring tools, Web developers, developers of non-browser user agents (like search engines), and so on. Each of these groups has different, and sometimes conflicting, needs and opinions. How do you square these with each other in a way that makes sense?

Carefully!

It's a very difficult balancing act. The users have to come first, with the Web authors a close second, but the problem is that if we ever specify something that the browser vendors disagree with, they will just ignore the specification, and we might as well go home. If we write a specification that is ignored, we're just fiction writers.

Also, the needs of the users and the authors are often not what they tell you they are. I frequently hear requests from Web authors along the lines of, "We should add a feature to do X," and when you point out that there is already a feature to do X, they say, "Yes, but the browsers don't implement it." Which is silly, of course, because why would they implement the new feature if they didn't implement the old one? Similarly, authors ask for features to work around bugs in other features, instead of just asking for the bug to be fixed. A big part of my job ends up being reinterpreting what people are asking for into what they really want.

It seems like a good portion of the active members of the groups are on other continents. How do you balance the need to work with people all over the world, often in real time, with the need for a personal life?

I've basically ended up splitting my work day into two. I work about four hours in the afternoon, and then about four hours after midnight. This gets me online during most of the times that people are awake around the globe, while leaving my evenings free for my personal life. Luckily, this kind of work is not very time-sensitive, though. Also, a lot of the real communication is done by e-mail, which I check pretty much continuously while I'm awake.

Within the HTML 5 spec, there are changes to improve things like Semantic Web, accessibility, internationalization/localization (I18N, L12N), AJAX (and other Web 2.0 items), and so on. In the greater scheme of things, which of these do you think will have the greatest adoption rate in real-world usage? Which of these do you think will not be used as much as they should be?

I don't know. If there's one thing I've learnt through the extensive research we've done for HTML5, it's that authors, on the aggregate, act in very surprising ways that don't really match my intuition.

The features that don't end up being used will be cut. We've already dropped a lot of things over the years, and I'm sure we'll drop more -- many of the forms-related things in the Web Forms 2.0 proposal which we're about to merge into HTML5 are things that we'll likely be dropping. For example, the repetition templates proposal is almost certainly going to be dropped.

What are the top five "gotchas," surprises, and so on for HTML authors in the HTML 5 spec?

I'd love to say there are none and, if we knew of any, we would remove them!

Most of the "gotchas" in HTML5 are things that we've inherited from the legacy of the Web. For example, the address element is for contact information, not any address; the br element shouldn't be used unless you're writing something that really has a line break like a poem (generally people should be using p instead of br); and be careful when writing URLs, you have to escape the "&" characters by appending "amp;" after each one.

We've also introduced some unfortunate features of our own, though. One is that, while we've made it legal for the a element (used to define links) to contain entire paragraphs and lists, doing so can cause problems in browsers like Firefox that don't yet implement the HTML5 parser algorithm. Also, while it can contain what we call "flow content," it can't be used to wrap individual list items or table rows.

If you could go back in time to the original HTML spec, what is one thing that you would change in it to make the Web a better place today?

Defining error handling from day one has got to be the most important change that I would ask Tim to make if I could speak to him then. I think we could have avoided a huge amount of the tag soup mess we have now if we had just defined simple error handling from the get-go.

It seems like being the editor of such a major work is a job that involves juggling a lot of differing opinions, trying to work with many software companies that are in fierce competition, and many other thankless tasks. For you, what is the most rewarding part of this?

HTML5 has had a big impact on the Web and the Web standards community.

We've raised the bar of what a spec has to do to be taken seriously; we've shown that it is entirely possible to develop Web technologies in a radically open manner; we've driven innovation and competition in the browser space; and we've shown that an open and vendor-neutral technology stack can compete seriously with single-vendor closed technologies. So it's great to know that I'm a part of that.

I've also been really happy with the community that has grown around the WHATWG. Many people have stepped forwards and taken part, not just commenting on the proposals, but also helping with the infrastructure, maintaining the blog, the wiki, the forums, helping new members out, and so forth. It's just been a lot of fun.

In closing

Thanks again to Ian for taking time out of his incredibly busy schedule for this interview.

As an example of how rapidly things change in this process, the "alt attribute" that Ian said was a contentious item has been changed quite a bit since the interview. You can see in the mailing list archives how the issue was handled.

Are there questions that you wish I would have asked Ian about HTML 5? If so, I'd love to hear them. Please post your proposed questions in the discussion forum.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

-------------------------------------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

46 comments
wjervis
wjervis

When I hear that HTML5 adoption will be the demise of Silverlight and Flash, what does that mean? And why is that the case? Why is Silverlight retreating to the mobility world (why would it be technologically more sustainable in the mobile paradigm vs. any other platform such as a desktop PC)? Why is Apple so adversarial towards Silverlight and Flash (technologically speaking)?

Violetw
Violetw

I've been involved with the internet since it was ARPAnet and I was also one of the original SGML template designers. Do I care about HTML5? No. Why should I? Is no one paying attention to the I.T. world? What makes you think anyone will be using HTML in the next 5 years?? Sheesh, wise up ppl!

mikifinaz1
mikifinaz1

Once upon a time, it was nice to make a web page as a user and I think that the initial ease of use drew in lot's of people and probably made the web what it is today. I however see the seeds of the death of the average user participation. It seems that in building all the trick functionality like CSS and now the additions of HTML 5 "the regular guy" is being lost. A tier of simple application should always be part of the web to provide a door way for users. A shame really, since many in the industry gained access as a user.

seanferd
seanferd

I am now curious to know what is going on with b and i. I suppose I'll go have a look-see.

Justin James
Justin James

HTML 5 is a long way off from being a spec, but that doesn't mean that some of its features are not being implemented yet. Are you curious about HTML 5? Is there anything about it that you would like to know more about? J.Ja

Justin James
Justin James

I agree as well. In fact, this was part of my motivation for joining the group in the first place, looking out for average HTML authors. There are a number of other people in the group doing the same. Indeed, everyone represents a special interest of one sort or another, mine just happens to be "HTML authors". :) J.Ja

orcmid
orcmid

I was just using HTML 5 as an example of a convergence effort around the web. Seeing Ian's prediction of the long road (4 more years! Sounds familiar) ahead, I must adjust my optimism around this. Nice interview packed with goodies. Thanks Justin.

mattohare
mattohare

I did get a kick out of him saying that some 'wants' are to work around bugs. I do hope the next standard will split the functions of the alt tag. I like to fill it in for accessibility, but most of that text does not need to show while a person with sight holds the mouse pointer over. I've wanted to put complete descriptions of images in the alt tags, but they'd just cover the entire picture if a person put the mouse over the picture. I've often wanted a separate 'keycap' attribute, or the like. It would be nice to have a multi-column element so I don't have to carefully divide lists into three separate divs. Also, predictable non-comformance would be absolutely wonderful! I'd love to see that now.

micd2
micd2

Is Mr Hickson's ad-hominem against accessibility experts really necessary? Surely such bile and rhetoric only serves to further demonstrate that Hickson is not fit to lead the HTML 5 Working Group, or serve as editor. The people he scorns with the phrase "so-called accessibility experts" have enriched the knowledge and wisdom of building accessible websites. As I pointed out in AbilityNet's recent Accessibility 2.0 conference (on the closing panel); the hard work and due dilligence by people like Steve Faulkner, Gez Lemon, Joshue O'Connor, Patrick Lauke have ensured that the term Accessible Ajax isn't a laughable oxymoron, but an actual vital collection of insights and best practice. This purposefully dismissive soundbite from Ian Hickson is unwarranted, unprofessional and unbecoming of a W3C Working Group Editor. This is not in keeping with ensuring that the World Wide Web can be accessible to people with disabilities. And it certainly doesn't play a constructive part in solving an issue that needs to be solved properly. Mike Davies.

dixiedi
dixiedi

As much time over the past 10 years as I have spent helping the casual html author I have come to the conclusion that it does not matter what the specs are. They are going to do what they want, the way they want and as long as it looks good to them,in their own browser, they don't care. If they are building a personal business site and they do not take the time to learn the specs then it is their business that will fail. If it is truly a personal site, it just doesn't matter because only 1 in a million internet surfers will see it anyway. But I still help them; trying to teach them to at least work in 2 browsers (IE and Foxfire), at 800X600, to keep it simple, to keep the color balanced and to load sometime in this century on a dial up. Anything beyond that is more headache than I can handle! Causal html authors, on average, don't have enogh education, however obtained, to take it any further than that and most (IMHO with 10 years experience teaching casual authors) do not care.

WebWatcher
WebWatcher

...to your images to preclude the covering of the image by the "alt" rendering in I.E. BTW "alt=" text doesn't show on hover in standards compliant browsers. To get that effect, you also have to use the "title' attribute.

WebWatcher
WebWatcher

... and I'll give you 7 different opinions on any given subject. Most of the most strident arguments will be from the "visual disabilities" community. While this is valid, it is also exclusive to that community and to the detriment of people with other disabilities. Just look at the current federal case in Canada. "http://www.bakerlaw.ca/Media%20Release%20- %20Blind%20MBA%20challenges%20federal%20gover nment%20over%20inaccessible%20jobs%20websites .pdf" (Yep, PDF) Her own web site, which offers "accessibility consulting" fails in so many ways, except of course if you're blind and use a screen reader. Her lawyer(s) site is a bit better http://www.bakerlaw.ca/, code validation could help. There are very few "accessibility experts" who view the topic with a holistic, non- biased, standard-based frame of reference. We are left with different "camps" which segment and fragment the accessibility community into disparate spheres of influence. What's the answer? I don't know. The only thing I can think of is "empathy". Put yourself in the other person's shoes, walk a mile and them come talk to me.

moyashi
moyashi

"ad-hominem"? "bile"? Mike, do you have high blood pressure and hypertension? If he had named names and made a vicious personal remark, that would have been "ad hominem." His comments were likewise free of bile. I'm sure you have good reason for your great sensitivity, but hey - chill out.

techrepublic.com.com
techrepublic.com.com

I'm sorry but I'm not going to pander to people who make claims without backing them up. There are plenty of people who work in the accessibility community who are part of the HTML5 effort who have done wonderful great work providing us with usability studies (e.g. Joshue O'Connor), making long and detailed studies (e.g. Ben Millard), and so on. People don't get a free pass just because they come from the accessibility community. In case it wasn't clear, though, I'm certainly not referring to everyone in that community with my comment in the interview.

mattohare
mattohare

Just by writing a credible book with popularity to rival the 'for dummies' books that completely explain the basics, and leave all the other stuff out. Thinking of it, this is really how everything works. You start with what you need in something and expand out. HTML is not really that difficult in the basics. Not given who I was able to teach it to. LOL

Justin James
Justin James

... a subset of HTML get made that has just what a casual author would need, to help them not get as confused. J.Ja

mattohare
mattohare

I've often told people to think of HTML as being like teachers that would put proofing marks on our papers back in school. That was quite a mark up language, figuring out all the odd little marks for caps, underlines, italics, spelling, etc. I agree, Justin, that a lot of the web comes from casual authors. They often don't need a lot. Give them the little they need, and we shouldn't have to worry about them abusing the other stuff that should not be there in the first place for text documents.

Justin James
Justin James

I agree completely about casual HTML authors. That's why I'm a bug proponent of trying to make the HTML spec something that the people writing authoring tools can an will follow. Authoring tools are more than just desktop Web editors (Dreamweaver, Expression Web, etc.), too! "Authoring tools" includes Microsoft Word and Publisher, it include the various Web-based HTML editing widgets for blogs and CMS's and so on. That's where some of the WORST HTML comes from, BTW. It was not until the last year or so, for example, that the extremely popular FCKEditor stopped using the "obsolete" (since 1999!) font tag, due to technical reasons! In my ideal world, HTML either gets generated by a tool/application that makes good HTML, or it gets hand crafted by someone knowing what they are doing. I would *love* to eliminate "casual HTML authors" as a group of users, but I know that it is an impossible task, especially since they are the source of much of the great information and content on the Web, even if their HTML is scary. :) J.Ja

WebWatcher
WebWatcher

It is not the spec, the law, or the right thing to do. It's the "craft" of developing/designing for the web. A true Craftsman knows, understands, and balances all of the variables in their domain. The web is still the "wild west" of Craftsmanship". We need to change that underlying perception. We need to advance the capabilities of the "WYSIWYG" tools and services beyond the "LEET" cloud-space. Any poor college student can tell you how to make a bookcase out of a couple planks and a few milk crates. It takes a few skills and some knowledge to make something your kids would be proud to say "My Dad made that". Frontpage design and the true "craft" of designing for the web leaves a huge gap in the knowledge factor. Browsers which are too forgiving of poor mark-up only exacerbate the problem. Web design, outside of "Facebook" or "Blogger", is a true craft. If you go there, "Here there be dragons". Focus on your craft, not what your IDE tells you it can do. Demand better of your tools and services. They may just listen.

Justin James
Justin James

I could not agree more. The W3C, from what I have seen, is a great example of the right hand not knowing what the left is doing. We have the WCAG doing their stuff with no real feedback loop to HTML 5, for example. You know what the problem is? UNIX. Huh? Let me explain. I think most of the people in this discussion are familiar with the UNIX model of development. You know how it is... anyone writing an SMTP MTA needs to emulate sendmail's command line behavior because that's the assumed behavior, their output needs to look like sendmail's, etc. In otherwords, the entire I/O model of any SMTP MTA needs to look *precisely* like sendmail (even if it optionally uses its own stuff), otherwise, anything relying upon sendmail fails. The W3C works like this. CSS development is 100% divorced from HTML, because even thought not a *single spec uses CSS other than HTML* (that I am aware of), they made it modular. "Just in case." What a load of nonsense. No one is going to hook CSS to something that isn't HTML, and no one is going to hook HTML to a styling system that is not CSS. Likewise, no one is going to hook a client-side language to the HTML DOM that is not JavaScript. And so on and so on. But, to satiate the "elegance nerds" out there, the development is completly split into a zillion uncoordianted project. Why in the WORLD would ARIA be developed separately from HTML? Is there a non-HTML use for ARIA that I am not aware of? Until the W3C drops this senseless idea of total separation of the spec development, we'll keep seeing this mess. WCAG should have been a subcomitte of HTML, same for ARIA, same for CSS. But W3C doesn't want to do it, so we'll keep having problems. :( J.Ja

dixiedi
dixiedi

All "governing bodies" appear disjointed, don't they? I couldn't help it a major election year and all. LOL I can see, simply because I can not see, how it works to get anything accomplished. The way I understand it, just about anyone can add their two cents worth, I would hope that all these pennies tossed in are at least considered; this alone would add years to any progress. There has to be groups of groups overseeing groups and meeting to eventually bring it all together. It could be very confusing but I am guessing. My wording, which has dropped to the level of a 5th grader at best proves I have little in the way of understanding the inner workings. I can't even hold an intellegent conversation.

WebWatcher
WebWatcher

@dixiedi: I'm not familiar with the inner working of the W3C or the processes involved. I can say, from the point of an outside observer, it seems very disjointed. It appears that there is little collaboration between the various WGs. One group is only focused on "this", while another group is only focused on "that", and yet another group is only focused on "the other." Throwing things out to the wild for comment without gaining acceptance from the other disciplines seems like inviting controversy. Consultation with the other WGs must be strictly regulated as in "You have until (YYYY:MM:DD) to respond or it will be presumed you agree." Internal debate is then very focused. I am currently part of a WG which is involved in developing corporate standards. The group is made up of a diverse representation of perspectives; policy, governance, programming, accessibility, standards compliance, and evaluation. We meet once a week and try to move very quickly. We have agreed to work in a "consensus" model. Positions are taken, discussed and voted on. Every two weeks, or month, depending on progress, our is workcirculated to two other WGs for comment. A lot of our efforts are based on existing open standards and we all have a strong respect for each others opinion and point of view. I believe it is our diversity and our respect for that diversity which contributes to our current progress. We also have a strong, diplomatic (mostly) coordinator who is quite good at encouraging consensus. I look forward to our WG sessions as a refreshing escape from my daily "battles." WW.

seanferd
seanferd

Reply to the post that is one level up, or reply to the very first post or article, which will give you more branching room.

WebWatcher
WebWatcher

There are many, many accessibility misunderstandings. This happens on all sides of the issue. People with disabilities and those who support them, know what affects them. Then there are the misunderstanding of how people with disabilities actually use computers. This is where it can get weird, wild and wonderful (all at the same time!). To play off the "quadrapelgic" reference, it could depend on whether we are talking about a high-level-quad with extermely limited/no upper body mobility or or someone who has gross motor function but may lack the dexterity to effectively use a mouse. Which ever one we are talking about, I can almost guarantee there is a why to interface with almost any application. This could be as simple as assistive mouse software or as complex as an eye gaze system and clicking by blinking. I've supported many people with many disabilities and some with multiple disabilities (including myself). P.S. note to dixiedi@: I caught a "message limit" on the thread discussing the W3C, I can't answer you there. Sorry It was getting good.

mattohare
mattohare

...in a different area though. They were so busy putting in switch-back ramps (that I call fish ladders), that they didn't put in stairs in some obvious places. I have a foot disability that is invisible most of the time. It means that I'd like to walk shorter distance rather than longer ones, even if it includes a few steps. Tesco's dead on for the wheel chairs (if they can get around the trolleys abandonded on the rampway) but not for people with foot disabilities, that still actually use their feet.

Justin James
Justin James

I've noticed the same thing too. I have a hunch that many of the people in accessibility have a very personal reason for being there, whether it be a disabled family member or friend, or even that they themselves are disabled. As a result, I have often seen something in the group that might not lead to complete accessibility be treated as an assault on an individual, with some messy results. To me, the irony is that probably 99% of the effort I have seen on "accessibility" is very narrow minded: it only cares about *vision* impaired users. It was not until last week when I brought it up, that I saw any kind of serious discussion around *hearing* impaired users. And I am interested to see how people respond when the topic of *mobility* impaired users comes up. With all of the AJAX-ification that's occuring, without something like a strong enforcement of ARIA, there is no way that a quadrapelgic could really use the HTML documents that HTML 5 really enables. It is important for all of us to remember that "accessibility" covers an enormous range of disabilities and circumstances! J.Ja

WebWatcher
WebWatcher

I'm glad you are qualifying that as "financially feasible" rather than impossible. Otherwise I'd have to sharpen my fangs and break out my "ACME ahole-o-matic". (_8(|) I stop before blood, I hate the sight of blood. I try to understate my qualifiers of my contemporaries when speaking publicly. I look at the recent debate about the requirement, or not, for the "alt" attribute in HTML 5 where one of the exemplars was Flickr's lack of capacity to accommodate the attribute. Would it really be so hard to add the option for the user to provide content? I'm not saying retroactively, that would be onerous. As a go forward approach, it would actually be a feasible option. That way, it is the submitter who takes responsibiity, not the site owners. /Withdraws fang and packs away gear/

dixiedi
dixiedi

Rabid is just a bit light on the diagnosis, don't you think? I would have gone for vampiric. They don't just want to tear you a new ahole, they want to bleed you dry afterward! LOL But I do understand, just hate trying to repeatedly explain my rationale for why not all sites need to be accessible to all. It's just not financially feasable.

dixiedi
dixiedi

Do you think it can be reconciled? There are so many diversities, so many variables to expect to ever reach any kind of balance. That does not say we should not strive for it. It would be the same as you or I striving for perfection, you have to reach but you also have to understand you will never get there. Taking that back to the original HTML 5 interview - the goal is to come up with a spec that would achieve balance for all. However, no matter how hard we try that will never be achieved so does it make sense to spend 10 + years trying? Wouldn't it make better sense to spend that time and energy on swaying those who create browsers to be less compliant? Don't get me wrong, I am all for HTML 5 and authoring compliance and accessibility within reason. I am tossing up a question that will hopefully draw out some interesting thoughts.

WebWatcher
WebWatcher

A middle ground would be an ideal resolution. This then raises the question of governance at the W3C level. How do we reconcile the various and sometimes seemingly contradictory objectives of the W3C Working Groups? HTML 5, WCAG, ARIA, WHATWG, UAAG, ATAG, ... From a Risk Analysis point of view, each group is a potential point of failure in achieving the foundational principles of the WWW? I won't add the Tim Berners Lee reference, we've all see that one enough.

WebWatcher
WebWatcher

Very few people come into the accessibility field without bringing some personal baggage. This baggage often gets dumped upon innocent developers/designers (D/D). Nobody goes out of their way to intentionally exclude anybody. Heck, we all want to attract and keep the most customers for our clients. D/D's just can't know everything all at once. Many accessibility experts (whether self-proclaimed or experiential and community declared) can come off as being the equivalent of rabid activists. They don't mean to, really. It seems to me that they forget that when a D/D asks a question, or makes a simple mistake, that it may be the first time that D/D has been confronted with that situation. They (We) sometimes fly-off-the-handle (guilty) but please understand this is the "n-th" time we've seen the same issue. Our tolerance level is occasionally a little low. You should see us when we are debating with someone that we KNOW should know better, we're downright nasty!

Justin James
Justin James

Yeah, I know what you mean. I too fall into a "middle ground". My goal on the topic is to get the spec to *allow* for (with proper hooks) HTML authors to make their documents as accessible as possible, not just to vision impaired users, but to *all* disabled users (99% of the "Accessibility Arguement" centers around vision-impaired users). At the same time, I feel that any attempts to mandate or force HTML authors to make their documents accessible is not likely to result in more than a few percent of documents being changed. Then again, that's still millions of documents. One idea that was floated that I liked a lot, was to create a 3rd category of HTML validation, insteasd of pass/fail... add "inaccessible". So this way something would be valid, but indicate that it doesn't have any accessibility on it. That would go a long way to raising awareness amongst HTML authors, I think. J.Ja

seanferd
seanferd

There was nothing going on here, last I posted. Just checked in to see the "attack on accessibility", which I do not believe was intended. Someone misunderstood, or has a bug in his ear. I just figured more folks would have something to say about HTML 5 in general.

dixiedi
dixiedi

I hesitated to see where the conversation was going. I really try to stay out of the accessibility arguement because I see no reason for a site that is built for people to LOOK AT to go all out for accessibility. I've gotten myself into many an arguement over it an just hit the back button as soon as I saw the word! I did however totally enjoy the the original article/interview. I am anxious to see how the 5 standards will make browser compatibility a lesser problem than it is now. I admit, I am guilty of using the alt tag to give sited visitors more info than I could fit elswhere while keeping navigation (in particular) neet and tidy. It's the only reason to still use buttons for navigation IMHO, even if they look more like text than buttons. Ooops another accessibility issue! I better get out of here now before I am bombarded by the pros for not making every site I've ever worked on totally accessible for everyone!

WebWatcher
WebWatcher

You're right. I probably should have pointed that out instead of just linking to the spec. Everybody love to read specs, don't they? The cautionary not to those who read this stuff is: "Values of the title attribute may be rendered by user agents in a variety of ways." It then goes on to point out "visual browsers frequently display the title as a "tool tip"". Thanks for reminding me to be more clear.

Justin James
Justin James

It is important to note that the behavior of providing a tool tip is *not* defined by the spec. In fact, most of the behavior we see in Web browsers is not explicitly defined by the spec. So beware when counting on a common "side effect" of a particular tag or attribute, since it can change in the future. :) J.Ja

mattohare
mattohare

I have two friends that use audible browsers and one that is colour blind. (Ok, he's from Idaho, I guess he's color blind.) I do something to the site, I have them give a few test pages a go. Not only do I listen to what doesn't work, I listen for what gets in the way. I keep my pages simple. I've always tried to stay away from using tight formatting just because it takes away from users' choice. I went into this in browser statistics. For me it's about reaching the most people with what they want. I'll put off a few on the way, but I doubt for long.

cdrates
cdrates

I agree, you can't generalize in either direction.