© graph from Google.
]]>The WAI-AGE project has just published a document explaining the needs of older people with Web accessibility needs due to ageing. There is a lot of information in this report.
Depending on the organizations, an older adult is a person who is 50+, 60+ years old. They are not technophobes. Far to be, I know a few older adult persons in my friends, who spend almost more time than me on the Web, searching for information of any kind.
Web Accessibility for Older Users: A Literature Review is a very good read, easy to understand.
]]>I have spotted on Ferris at least two projects which are (or in the process of) using a combination of SVG and XMPP for creating whiteboards.
Niklas has also made a proposal for a protocol for whiteboarding in Jabber using SVG and XMPP.
]]>Dr. Hellman (at door, left) Music is a wonderful thing, you know. You should have been listening. There's something ennobling about it, soothing …
We like it too. The Web has given a unique opportunity for everyone to link data, to share, to reuse and create. BBC is one of my favourite source of news. I like their site and I like their mission statement. Tom Scott (BBC Radio Labs) says in a blog post on helping machines play with programmes.
As part of our work on developing BBC Programmes we have been looking at how we can make the data available for other development teams outside the BBC.
and
We have been following the Linked Data approach - namely thinking of URIs as more than just locations for documents. Instead using them to identify anything, from a particular person to a particular programme. These resources in-turn have representations, which can be machine-processable (through the use of RDF, Microformats, RDFa, etc.), and these representations can hold links towards further web resources, allowing agents to jump from one dataset to another.
He is asking the community for comments around the RDF version of their schedules before publishing them along the other formats. There is also a cool demo which sends you notification of programme start. It should not be too hard to plug that into a Jabber client. In their demo, they are using Growl.
]]>Why? Well, the massive use of Web technology to develop and deploy those services already made the Web a crucial tool for eGovernment.
We have learned quite a number of things so far. Services are getting more and more sophisticated. It's not just that you can get information online or download a form, fill it and walk to a government office in person to give it to a public servant. You can do the whole process online. What is more, in some cases, the "paper" service is even disappearing and users are faced with just its online incarnation.
At this moment in time, is more important than ever to do things well, and Web standards are in the heart of it. In the rest of this post, I review some of the most important challenges we found so far, and what we are proposing to tackle them.
Governments are spending huge amounts of money in building those services but their usage (especially of those availables for citizens) is low. Originally, governments were putting services out there in the same way they've been doing for years. You, as a potential user, need to know what government agency is in charge of a given service in order to be able to find it and use it. This was not working well. Citizens are not aware of the government internal structure. Fortunately, things are changing and governments are putting strong effort in building a citizen-centric experience. This means that they put themselves in the role of their users and try to build what the users expect. Part of this effort are the so called "one-stop stops", government portals where, no matter what agency or department is in charge of a given service, are built in terms a user can understand and make available the whole offer of government services on the Web.
Governments are finding benefits in using open standards, so many W3C standards are used to build those portals and services, and the Web Accessibility Content Guidelines (closer to turn 2.0) are among the most widely known and used. What is more, many are building their own National Guidelines for Public Sector Websites or, more generally, their Open Standards policies on their own.
Going back to the portals. Do you know what the one of your government is? Don't be afraid if not. Most don't. And most of the times the number of services available there are in the several hundreds or well over a thousand ones... Anyway, you try going to a search engine and many times you find the information you are looking for somewhere else or don't find it at all.
Governments are recently putting much effort in engaging users in the use of these online services. The portals are a step in the right direction and another is to put the information where the users are looking for it, on the Web sites they use regularly to find videos, photos, information. This requires more resources and new expertise and new challenges arise. For example, if a government agency puts up a blog and get comments, what should it do with them? What if those comments could eventually improve the information that the government already had about the information exposed? How do the new information compare to the authoritative one that the agency already had in its systems? All good questions, most still unsolved.
This increasing effort in getting the users participating more is also accompanied by a increasing one in getting the most information out there for them, also not without challenges. It's usually very difficult to discriminate from the information the government already has, which one can be made public a which one cannot. In case of doubt, government tends not to release information. It's too risky.
There is a clear need to improve information systems. They need to evolve into smarter ones. On one hand, it's important to annotate the provenance of the data archived there somehow, so other systems could query it and learn for what purpose that data was collected and if it's reusable or not and until what extent. On the other, it's about time to end with information silos and achieve a seamless integration of data. Semantic Web is here to help and there is an increasing number of successful use cases already. And once you are there, why not open your data? I'm sure you are aware of the usefulness of many application mashups, can you imagine what new possibilities government data mashups can open? Maybe the Open Government Data Principles could give you a hint on why this would be a good idea.
Is this all? Of course, it's not. There are other eGovernment challenges out there (identity, security, integrity...) and some are not just government specific but would need a solution somewhere else (e.g. other technical Activities at W3C), but we believe we need to start simple and somewhere, and these are the most important and the ones that came up more often during the exploratory work so far.
We believe that the challenges described here are common to governments all over the World and that a collaborative effort between governments, industry, citizens, academia and other civil societies would have a strong beneficial impact in addressing them.
If you find this interesting, you are welcome to join us in the W3C Australia eGovernment Tour 2008, four talks in three cities in seven days, coming soon to a city nearby (if you are in Australia, that is) and take a look at what we proposed as a next step at W3C and comment on it, the sooner the better.
]]>This analysis is intended to be neutral with respect to ideology, history and constituency. For a useful overview of how we got here, see WAI-ARIA Implementation Concerns (member-only link) by Michael Cooper.
The W3C's WAI PF Working Group recently published the first public working draft of the Accessible Rich Internet Applications (WAI-ARIA) specification, which "describes mappings of user interface controls and navigation to accessibility APIs".
The ARIA spec. defines roles, states and properties to manage the interface between rich web documents and assistive technologies. The primary expression of roles, states and properties in markup languages is via attributes. Since ARIA is meant to augment web applications across a range of languages and user agents, ARIA has to specify how its vocabulary of attributes and values can be integrated into both existing and future languages.
In preparing this analysis, I have reviewed the available concrete evidence bearing on the matter, and have carried out a considerable amount of work to replicate and, in some cases, correct or extend, testing which has been done in the past. The details are available in a report entitled Some test results concerning ARIA attribute syntax.
ARIA is useful only if it is widely supported. It therefore needs to integrate cleanly into existing and future languages as easily as possible. Before looking at possible answers to the spelling question, we need to consider exactly what supporting ARIA means.
We can distinguish two levels of support for ARIA on the part of user agents, which I'll call 'passive' and 'active' support. By passive support, I mean that documents with ARIA-conformant markup are not rejected by the agent, and the markup is available in the same way any other markup is, e.g. via a DOM API or for matching by CSS selectors. By 'active' support I mean the user agents actually implement their part of ARIA semantics, that is, reflecting changes to ARIA-defined states and properties via accessibility APIs.
Although already deployed implementations cannot offer active support, an optimal answer to the spelling question would maximise passive support from existing languages, as well as encouraging active support from subsequent implementations.
There are in principle three possible approachs to the spelling question:
The land-grab approach is pretty clearly unacceptable, because of clashes with existing vocabularies and the likelihood of clashes with future ones, and will not be considered further.
The current
ARIA WD specifies a combination of the colon and
dash approachs, with the colon being specified for use
with XML-based
languages, with the necessary additional requirement that 'aria' is bound to
the ARIA namespace in the usual way, i.e.
xmlns:aria="http://www.w3.org/2005/07/aaa", and the
dash approach being specified for use with non-XML languages. We'll
call this the mixed approach hereafter.
My understanding is that as of the date of this note, the WAI PF working group have indicated that their intention is that the next draft of the ARIA specs will move to the dash appropach.
Choosing an approach is made complicated by the landscape of language and infrastructure standards it has to fit in to, and by the fact that these are moving targets. We therefor have to distinguish between what is currently in place, what we have reason to expect in the near future, and what we can foresee in the longer term. Furthermore, for existing languages we have two categories: XML-based languages, with more or less explict provision for extensibility in general, typically namespace-based, and non-XML languages, which for the purposes of this analysis we will take to be HTML 4.01 and nothing else.
As noted above, the best we can expect from deployed user agents is passive support. The table below sets out the extent of passive support which is available for the colon and dash approaches for each of three host languages, which exemplify the major relevant categories: HTML 4.01 (for the non-XML languages), XHTML (an XML language, but not always treated as such, so we actually get two columns for it below) and SVG (only an XML language).
Notes:
It should be noted that some of the entries above disagree with assertions made in the past about browser behaviour. At least some of those assertions were based on flawed test materials---see the discussion of experiments 1 and 2 in my testing report for details on the information summarised above.
A number of browser implementors have responded positively to the ARIA initiative and have included experimental active support for ARIA in pre-release versions of their products. Most of the test materials and implementation information I can find suggests that only the dash approach, and only HTML or XHTML, are currently being implemented.
With regard to improving passive support, it seems very possible that
IE8 will support attribute selectors of the form [aaa\:checked],
which would remove the qualification recorded in the table above by footnote 4.
The situation with respect to HTML5 is complicated. As it currently stands, the HTML5 draft specification supports namespaces internally, and all HTML elements are parsed into the DOM nodes in the HTML namespace, regardless of whether they are parsed "as HTML" or "as XML". But when parsing documents "as HTML", no other namespaces are recognised. Unless this changes before HTML5 is completed, the HTML/"XHTML (as if HTML)" columns above will apply to HTML5-conformant user agents in at least some cases.
On the basis of the above survey, there follows below an attempt at a
cost-benefit analysis with respect to the colon and
dash approaches, as well as the mixed
approach as currently specced in the ARIA working draft and a fourth approach, as proposed by me in
a
message to www-tag, which I'll call the xcolon approach.
The xcolon approach attempts to address some of the problems
revealed in the passive support table by defining a
pair of getter/setter Javascript functions for access to ARIA information in the
DOM, and giving a design pattern for duplicated CSS selectors (one using
[aria\:xxx] and the other [aria|xxx]).
aria prefix
and may not (i.e. in some browsers) correctly set the namespaceURI
property even when targetting an XML DOM.[aria\:...] selectorsFor wholly commendable reasons, development of the ARIA spec. and pilot implementation work have proceeded in parallel. Most if not all existing implementations support only the dash approach. What is the likely cost for those implementations of any decision to adopt any other approach? My conclusion, having examined one implementation in some detail, is that the cost is likely to be very modest.
Michael Cooper, WAI PF staff contact, captured the reason for this very well, albeit unintentionally:
"The ARIA roles and properties are conceptually simple enough, but they are designed to provide a bridge between HTML and desktop accessibility APIs, a bridge which is exploited by the operating system, user agent, and assistive technology all working together. There's a complex set of interdependencies there and the feasibility and details of many of the ARIA features could only be worked out by testing in deployed systems, and therefore doing early implementation."
The complexity referred to above is fundamentally one of architecture, both static and dynamic. Not surprisingly, therefore, syntactic concerns account for a tiny fraction of the code needed to implement ARIA as it stands. Furthermore, and again not surprisingly, as it's what sound software engineering practice requires, the details of the concrete syntax are isolated, and the vast bulk of the code I looked at refers to it only indirectly. The consequence of all this is that the changes necessary to manage any change away from the dash approach will be very straightforward. For more details, see the discussion of experiment 3 in my testing report.
Many existing XML languages make explicit, generic, provision for extensibility by including in their formal schemas and/or spec. prose allowance for any namespace-qualified elements and attributes from namespaces other than those which make up the language itself. Tools such as NVDL and, to a lesser extent, W3C XML Schema and RelaxNG, make it possible to combine the schemas for multiple XML languages to give a complete characterisation of mixed-language documents.
One particularly important example of this approach is SVG. ARIA integration into SVG is clean and straightforward under the colon or mixed approaches, but will require amending the spec. under the dash approach.
In trying to weigh the tradeoffs which must of necessity be considered when confronted by the information given above, the matter of timescale is particular hard to address. Any assertion about how things will look five, or even two, years hence can always be countered with a contrary assertion. None-the-less, the centrality of the HTML languages for the Web, and the fundamental importance of accessibility for all of us, suggest that we must take the long-term impact of this decision seriously, and be prepared to discount some short-term discomfort in return for long-term stability and simplicity.
© graph from Google.
]]><Hixie> ok for canvas text my proposal is:
<Hixie> drawHString(x, y, maxWidth, textAlign, s); and drawHString(x, y, maxHeight, textAlign, s);
<Hixie> drawVString(...) for the second one
<Lachy> what's the difference between them? drawVString for vertical stings where the letters are stacked on top of each other, and not just rotated 90 deg?
<Philip`> Hixie: They look complex and hard to use :-p
<Philip`> compared to e.g. translate(x,y);drawString(s)
<Hixie> lachy: drawVString() would be for vertical text (e.g. some CJK)
<Hixie> one is lack of support for vertical text :-)
In printed media, it is handled quite well for a long time. Japanese books have some complex layouts mixing western and japanese characters.
It happens not only in CJK (Chinese Japanese Korean) texts. Think about a neon sign of an hotel with the letters written vertically.
Felix Sasaki is my colleague at W3C/Keio and has worked with the Japanese Layout Task Force. He was sitting next to me when I was reading the logs of the discussion, so I just asked him some references. He sent me a link to 1.3 Directional Factors in Japanese Text Layout from the Requirements of Japanese Text Layout. He also reminded me about XSL 1.1: 7.29.3 "glyph-orientation-vertical" .
Wikipedia has a page on the topic of Horizontal and vertical writing in East Asian scripts and Unicode a note on Robust Vertical Text Layout.
All of that should help to define the API for Canvas Text.
]]>http://www.w3.org/2001/sw/Overview.html for the HTML version and a separate http://www.w3.org/2001/sw/Overview.rdf for RDF (remember that W3C’s Apache setup is such that the default index file is called “Overview”). But this would lead to versioning problems; not a good idea!
This is where RDFa comes into the picture: don’t duplicate information if you can avoid it. Instead, add the RDFa attributes to the HTML file and let the machines do the rest. And this is what has been done. If you look under the hood, http://www.w3.org/2001/sw/Overview.html is, in fact, in RDFa, ie, the core (X)HTML information is enriched with some attributes that allows the automatic generation of corresponding RDF data.
The best is, of course, to look at the source to see the details; here is just an example. This is, essentially, how an entry on a recommendation looks like in XHTML+RDFa:
<li resource="http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/"> <a rel="doc:versionOf" href="http://www.w3.org/TR/rdf-syntax-grammar" property="dc:title">RDF/XML Syntax Specification (Revised)</a>, <span rel="rdf:type" resource="[tr:REC]">W3C Recommendation,</span> <span property="dc:date" content="2004-02-10">February 10, 2004,</span> <span rel="tr:editor"><span typeof="contact:Person" property="contact:fullName">Dave Beckett</span></span>, ed. </li>
yielding, in RDF:
<http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/> a tr:REC;
dc:date "2004-02-10";
dc:title "RDF/XML Syntax Specification (Revised)";
doc:versionOf <http://www.w3.org/TR/rdf-syntax-grammar>;
tr:editor
[ a contact:Person;
contact:fullName "Dave Beckett"
].
using a number of existing vocabularies (eg, Dublin Core or the “TR” vocabulary that W3C has been using for years to describe its documents).
So how would one set up the server to get the right version of the documents for the right request? Although, at some point in time, one could expect that (RDF) browsers will just pick up the RDF information automatically, what to do in the meantime? What one would like to have is:
http://www.w3.org/2001/sw/ should return
http://www.w3.org/2001/sw/Overview.rdf should return RDF/XML, generated on-the-flyhttp://www.w3.org/2001/sw/Overview.ttl should return RDF in Turtle, again generated on-the-flyhttp://www.w3.org/2001/sw/Overview.html should return, obviously, XHTMLA bit of Apache Wizzardy works here. First a special Apache file is created to control content negotiation. The usual setup is to associate this to the “var” extension, ie, Overview.var in this case. The file itself looks fairly simple:
URI: Overview URI: Overview.html Content-Type: text/html URI: Overview.rdf Content-Type: application/rdf+xml; qs=0.4 URI: Overview.ttl Content-Type: text/turtle; qs=0.5
that will instruct the Apache server to choose the right file depending on the accept header. HTML will be returned if both HTML and RDF/XML are accepted; and Turtle is preferred if both RDF/XML and Turtle are accepted by the client (that is the role of those “qs” values).
That takes care of the content negotiations, but we are not yet done because, remember, the goal is to generate the RDF/XML and Turtle versions on-the-fly. This is achieved by adding the following lines to the .htaccess file in the directory:
RewriteEngine On RewriteBase /2001/sw/ RewriteRule Overview.rdf /2007/08/pyRdfa/extract?uri=http://www.w3.org/2001/sw/Overview.html [L] RewriteRule Overview.ttl /2007/08/pyRdfa/extract?format=turtle&uri=http://www.w3.org/2001/sw/Overview.html [L]
that instructs the server to run a script (ie, the RDFa distiller) on the (X)HTML file when an RDF/XML or Turtle versions are required.
That is it… (And thanks to Ralph Swick and Tim Berners-Lee who gave me the right push and information to handle Apache.)
]]>… tell me what you think are some of the font styles and features missing from the current specification. What do you expect to be able to do with typography on your Web pages that you can not do now? What are you doing now with kludges that you would like to see simpler ways of doing? Keep in mind that we are talking about font properties and how to style the characters. This includes things like bold, italic, and even outline and emboss which effect how each glyph is rendered. It does not include styles that area applied over an entire block of text such as underlining or rotating text. Those are in different modules.
Also, let me know what you think about some of the new additions to the Fonts specification (font-size-adjust, font-stretch, font-effect, and font-smooth) and any problems you have with the current specifications.
Try to be as specific as possible, and provide examples and links if you can. I’m looking forward to seeing what the Web design community comes up with!
Go add your own comment on his blog. I know at least one person who should send his comments. We had often debates about typography, CSS and standards in the French blogosphere. ;)
]]>The mice think they are right, but my cat eats them anyways. This is the point, reality is nothing, perception is everything.
We all live in our own world of perceptions and the world is shaped with these. I have read recently read a blog post by Arnaud Le Hors saying:
Having been primarily involved in W3C both as a staff member and a member company representative I had grown to expect a certain quality level which has led me to be genuinely baffled by the whole OOXML experience. I just didn’t know how superior the W3C process was compared to that of ECMA and ISO/IEC. I just didn’t know those organizations had processes which are so broken that they would allow such a parody of a standards development to take place and such a low quality specification to be eventually endorsed as an international standard.
There have been discussions within the W3C for a long time as to whether it should seek to become a PAS submitter and adopt a policy to systematically submit its standards to ISO/IEC. I used to think it should. I no longer think so. The W3C process is so superior to that of ECMA and ISO/IEC, it’s these organizations that need to learn from W3C and those who are working for the W3C standard label to be recognized at an international level in its own right have all my support.
Arnaud's words touched me; the full article is worth reading. It reminded me of my time working with Web technologies (in Web design agencies and organizations) prior to my W3C hiring. I was very condemning about W3C and its standards development. Then with time, with the accumulation of experiences and understanding, I realized (more than knowing) that the platform which is offered by W3C is a good compromise.
For sure, my words will be taken suspiciously because I'm right now an employee of W3C. Nothing is perfect at W3C. There are still issues, but the organization is flexible enough that it knows how to evolve when necessary. People have a tendency to forget this. When I have been hired almost 8 years ago, the notion of test suites for a W3C specification to be published was considered as a big burden and not in the scope of W3C Working Groups. One of the reasons, I had been hired at this time was to change this mindset. It has been hard, painful sometimes, but we did it. The "we" include some W3C members, the wonderful participants of the former QA Working Group and the dedicated work of the W3C QA Team, including Dominique Hazaël-Massieux, Olivier Théreaux and myself.
It is sometimes hard to understand how W3C is working. I have in the past tried to explain how all pieces fit together on mailing-lists or here on this blog. I see comments on mailing lists and blogs which should not be said, harsh words between people. Be careful about your perceptions, assumptions, they lead you sometimes in fights. This is not right.
W3C is a community platform where people can work on Web technologies with different tools. One of these tools is the W3C Process. Use the tools for working.
]]>I hear you asking, "When will it be completed?" We're optimistic that it will indeed be completed in 2008. If implementation goes well and there are no significant new issues, the "Proposed Recommendation" of WCAG 2.0 should be published in the third quarter of 2008, with the final Web standard W3C Recommendation published about two months after that.
What's important now is that we need your help moving WCAG 2.0 to the next stage. In order to advance WCAG 2.0, we need to demonstrate that it can be implemented in different types of Web content, in a variety of human languages, and using a variety of technologies. We're looking for several websites that conform at each level (A, AA, AAA), and at least two independent implementations of every success criterion. (Success criteria and levels are introduced in Overview of WCAG 2.0 Documents.) We welcome WCAG 2.0 implementation experience from a wide range of environments, including e-commerce, government, education, blogs, etc.
Note that there are a few success criteria that are at risk of becoming advisory if we don't get at least two implementations of them. Here is a special appeal for implementations of those at risk success criteria.
To be a part of this stage of WCAG 2.0 implementation experience, check out WCAG 2.0 Candidate Recommendation Implementation Information.
There are a lot of reasons to start implementing WCAG 2.0 now, in addition to the possibility of your website being publicly listed as an implementation; see "What are the benefits of using WCAG 2.0?" in the WCAG 2 FAQ.
Thanks for all the support moving WCAG 2.0 towards completion!
]]>Summary:
<font>is gone,style=""is made global.
What does it mean? The font element is part of the list of active formatting elements . The browsers (user agent) have to support the content which is available online following the guideline "Do not break the Web" but the font element has disappeared from the content model.
Basically, there is no way to use a font element to write a conforming HTML 5 document. You, or the authoring tool, will have to use the style attribute.
alt attributes on HTML WG mailing list. It's always difficult to move forward in such discussions because it seems to be easy when in fact it is rather complicated. The issue involves many parameters: the author, the reader, the authoring tool or CMS, the usage pattern on the Web site and the user agent. To really be effective, we have to understand how the alt is being authored with tools.
Steve Axthelm has sent an email describing the behavior of a few tools. Laura Carlson followed-up. Having more authoring patterns in different environments such as web services would be useful too. The list of tools so far is
Karl mentioned before on these pages one of the tools we have been developing, but I would like to focus today on our most recent (and rather exiciting) deliverable: the Web Compatibility Test for Mobile Browsers.
That test, in the same spirit as the ACID tests, combines in a single page tests for 12 Web technologies, ranging from well-deployed (but often poorly implemented on mobile devices) technologies such as HTTPS and PNG, to technologies we believe will matter in a year or two (like SVG animation and CSS Media Queries).
Tests are visualized by squares, sorted roughly in order of difficulty (first line, well-deployed technologies, second line, technologies increasingly used today, third line, technologies for tomorrow), and a browser needs to render each square in the same tone of green to pass completely the test - which as far as I know, no currently released browser (on mobile devices or elsewhere) does.
Enough words, everybody wants to see pictures, so here come a few screenshots of the test rendered in a variety of browsers:
Blazer 4.3.2.1
Opera Mini 4.1 beta 1
PSP's Netfront
Android emulator webkit-based browser
Firefox 3 beta 3
Internet Explorer 6
Running the test is as simple as pointing your browser to its address, namely http://dev.w3.org/2008/mobile-test/test.html.
Entering an address is a pain on a phone? Quite often, indeed, so a couple of alternatives to save you a bit of that pain:
http://tinyurl.com/37e33pWant to help us with this? Here are a few ideas of how you can contribute to the impact of this test on interoperability:
wct tag;The general scope of the proposed Video on the Web activity is to provide cohesion in the video related activities of W3C, as well helping other W3C Groups in their effort to provide video functionalities. In addition, this activity will focus at implementing the next steps from the W3C workshop on Video on the Web. The proposal is to create 3 new Working Groups around Video on the Web. Please, have a look at the following documents:
We welcome general feedback, general expressions of interest (or lack of!) and comments on the discussion list public-video-comments@w3.org.
If you should have questions or need further information, please feel free to contact me as well. I will be presenting the activity proposal during the Web Conference next week, on Thursday afternoon.
]]>alt attribute should always be required on images. And Henri Sivonen is among the most active participants in that discussion, posting to that thread (among other messages), the following:
http://lists.w3.org/Archives/Public/public-html/2008Apr/0322.html
http://lists.w3.org/Archives/Public/public-html/2008Apr/0333.html
The question of whether or not alt should always be required is an issue that affects the behavior of validators, so it shouldn't be much of a surprise to see Henri taking interest in the discussion around it, because he maintains a validator (more precisely, a conformance-checking tool) called Validator.nu that he's spent a lot of time developing and that he clearly wants to be a beneficial and serviceable as possible to the people who take time to use it.
Among the assertions that Henri makes in his postings to that thread is the following:
An HTML5 validator isn't an accessibility evaluation tool--or at least I think it shouldn't be.
He goes on to compare the purpose of a validator to that of a spell checker, and in a later message, adds this:
A validator cannot check that a page is semantically correct. It can't properly check for accessibility, either.
We should dispel misconceptions about what validators do instead of catering to the misconceptions.
And to clarify what he intends Validator.nu to be useful (and not useful) for, he adds this:
The validator I develop is not a stamping tool. It is a tool that helps authors detect mistakes that they didn't intend to make, so that they don't need to spend time wondering about the effects about their unintentional doings. For example, the validator I develop helps author detect that the alt attribute was typoed as 'atl', which is useful, because atl wouldn't work... I'm not interested in developing a formal stamp. I am interested in developing a development tool.
The assertion that earning a "this page is valid" stamp or badge should not be an end goal (or any kind of goal at all) for users of a validator or conformance checker is something that Henri has stated consistently since the earliest public versions of Validator.nu were available (and that others have been stating for quite a long time also) -- as is the assertion that a validator should be a development tool, not a tool for advocacy. Henri states that most succinctly is a section of the Validator.nu FAQ:
Validation is a tool for you as a page author -- not something your readers need to verify.
To make a somewhat ham-handed analogy of my own: Consider the case of when you create a document with a word processor like Microsoft Word or whatever and you run in through that application's built-in spell-checking and grammar-checking tools to find and fix any spelling or grammar problems. You're using those tools as an author to ensure that the document doesn't contain any unintentional errors before you share it with others. And after you use them, you would never consider embedding a badge in the page to indicate that it's free from spelling and grammar errors -- because the fact that it is free from such is something of real value to you as an author, it's of no value to have it highlighted to all your readers, and not something you want or need your readers to verify.
Anyway, that (bad) analogy aside, I think Henri and most other reasonable people would agree that there is great value in encouraging authors to produce valid content, and beyond that, to encourage authors to be familiar with best-practice accessibility and usability guidelines and to try to follow them to the best of their ability. The main difference of opinion here is around what role (if any) validators should be expected to have in encouraging authors to do those things.
]]>This piece of code might be useful for someone and there will be certainly people who think that it is really programmed with my feet and suggest fixes. I usually work in UTF-8 but sometimes there might be character references and named entity in my files. So I wanted to convert everything to UTF-8 characters.
def parsefile(path):
try:
file = open(path, "r")
fileread = file.read()
fileread = unescape(fileread.decode('utf-8')).encode('utf-8')
file.close()
except:
print "Reading File Bug"
sys.exit(1)
return ET.fromstring(fileread)
The Unescape HTML Entities routine was found on Frederik Lundh Web site. The code was doing too much because it was converting &, > and <. I wanted to keep those in URL and where I have escaped code sections. So I slightly modified it for my own needs.
def unescape(text):
"""Removes HTML or XML character references
and entities from a text string.
keep &, >, < in the source code.
from Fredrik Lundh
http://effbot.org/zone/re-sub.htm#unescape-html
"""
def fixup(m):
text = m.group(0)
if text[:2] == "&#":
# character reference
try:
if text[:3] == "&#x":
return unichr(int(text[3:-1], 16))
else:
return unichr(int(text[2:-1]))
except ValueError:
print "erreur de valeur"
pass
else:
# named entity
try:
if text[1:-1] == "amp":
text = "&amp;"
elif text[1:-1] == "gt":
text = "&gt;"
elif text[1:-1] == "lt":
text = "&lt;"
else:
print text[1:-1]
text = unichr(htmlentitydefs.name2codepoint[text[1:-1]])
except KeyError:
print "keyerror"
pass
return text # leave as is
return re.sub("&#?\w+;", fixup, text)
Hope it helps.
]]>What I essentially experienced this week was an ultra-high speed lesson in techno-obsolescence. Instead of taking 18 months to become doorstops, my new machines arrived pre-obsolete. They now reside in a Rubbermaid bin, along with my Museum of Old and Incompatible Cords, Adapters and Laptops. In about five years, when the bin fills to overflowing, its contents will be sent to the local landfill to be unearthed in one billion years by whatever species it is that supplants us.
I have read on Dave Shea's blog about Mediatyping. Dave Shea relates is unfortunate experience trying to setup a stylesheet for his blog that will work on mobile devices. He first started his design by specifying the CSS media type handheld. Dave said:
But here's the thing about media-specific style sheets: the browser in question has to support them. Mobile Safari grabs all screen media style sheets, and ignores the handheld media type entirely. So despite good intentions, my efforts were wasted on it. And that's what led me down the road of user agent sniffing...
Dave went down the route of user agent sniffing. A discussion started on his blog to improve his code. A comment by Anil Dash triggered a connection with Douglas' article:
what about what we've learned about the inadequacies of media types in CSS? Screen? Mobile? TV? Those aren't useful distinctions. It's another classic example of spec failure due to inadequate prognostication abilities. Someday we'll have the ability to see the future and this will all be easy.
Chronos dream? We can't predict the future. A specification is here to fix time for a little while. The challenge is even greater for Web designers with the rise of ubiquitous computing. Small devices with a tremendous diversity in forms, size, capabilities factors and very short lifespan. W3C Working groups are working on these challenging topics. For example, Ubiquitous Web Applications is working on a new version of CC/PP. CSS WG is working on Media Queries with more customization capabilities. If a specification takes too much time to be released, it will be obsolete by the time it is published. If a specification is changing too often, people can't keep up with the changes and interoperability suffers. Finding the right compromise is difficult.
]]>My requirements are simple:
Given this input I would like to get a colored map such as this map for drinkable water access by Philippe Rekacewicz.
If it doesn't exist yet, it could be a nice and very useful tool for everyone else. If it exists, please leave a comment.
]]>The question of creating a public aggregation of W3C staff blogs has generated many discussions inside the Team. That's normal. We are a group of persons, a community. When there is a new project, a community gives time for discussing individual opinions. Questions were diverse, surprising sometimes, but there are just the mirror of what we are: humans.
That was a very interesting debate which is certainly not finished. We will have new people coming in the staff, others leaving, people might change their minds in the future. One important decision we made is to have an opt-in process. People from the W3C staff are free to join if they want and free to leave.
So here come the W3C Team blogs' Galaxy and its atom feed.
]]>Wait, wait before answering. Most of you reading me right now are geeks, computers addicted, working for the Web, intense users of the Web. I would like to hear the answers of people around you, in your family and your friends. I would like to hear the struggles of people who are just users of the Web without deep understanding of the technology.
Please ask them and report here in the comments, or on your blog with a link to here.
]]>Momus :
Moloch passed the message to the Behemoth
Whose master passed it on to Zebedee
It was sent by Internet, by obscure protocols
To its recipient, the delicious Miss Gee
And maybe I would continue with Gilberto Gil, Pela Internet (listen the music):
Criar meu web site
Fazer minha home-page
Com quantos gigabytes
Se faz uma jangada
Um barco que veleje
Internet is fun. What would be your geek song?
]]>W3C mailing-lists are where a lot of things happen, and so the organization has been dedicating a lot of resources to its mail infrastructure over the year, often being at the forefront of the fight against spam, so much that the "World Wide Web Consortium" sometimes get nicknamed "SMTP Consortium".
The flow of mail can be dreadful sometimes. For example, I think I must be receiving several hundreds, perhaps a thousand, of mails per day, from W3C participants or mailing-lists. And our system tells me that in my few years around here, I've sent over 10,000 mails to W3C lists.
It is fortunate that we have some simple but cool systems to manage this information overload:
Message-Id identifier. That's convenient! So we can use that to provide a simple, but effective gateway from Mail to Web, and immediately find any mail ever archived at W3C by its identifierWhat all these systems bring, in a nutshell, is a choice in how one can find, access, and work on this mass of information exchanged by e-mail. This choice is good: it really leverages the power of the public web, the ability to harvest, process and enhance data. So it is quite exciting to see how a new actor can take this data and do cool things with it.
Yesterday, the Markmail team announced that they were opening a new search interface to the public w3c lists, with more than 400,000 messages loaded (less than our in-house search system, but quite impressive nevertheless!). With some nice ideas and a lot of Web Technology magic (XML , XQuery, HTML, PNG, CSS, DOM...) they managed to come up with a very interesting interface indeed. I can only wish all this were open source ;) .
Beyond the mere value of being able to access the e-mail discussion contents via many interfaces, there is a serious lesson to be noted: what gets published on the public web is likely to stay on the public web forever. Indeed, even what we publish on our personal sites, content we feel free to "remove" at any point, may be indexed, cached, quoted, or even mirrored, copied, reused... Better try and behave accordingly.
]]>
This is one update we are rather proud of, with more than 50 bugs closed, a polished User Interface, and some changes to the core that will make checking of CSS stylesheets much easier and reliable. You can see a more detailed list of the changes in the announcement we made on the CSS validator's mailing-list.
How come, however, that it took us more than a year to push this release through? More than a year since the last significant "Fuji" release? A large chunk of the code was ready by the end of summer '07, but it did take us a few months to get all the changes translated into the many languages supported by the CSS validator (you may remember the calls for help sent to the translators forum or here on this blog) and make sure all the bug fixes were properly added to the validator's test suite.
I am very hopeful that with our improved way of tracking and fostering translations, and with the growing interest and help in the tool's development and translation (notably by opera software staff - thanks!) we can have a faster release cycle in the future. And that is fortunate, because there are some really nice changes brewing for this CSS validator: Yves and I will be blogging about the nitty-gritty-techie details of current work on the Systems Team blog, so watch that space too. And of course, as always when we start a new phase of development, now is a very good time to get involved, so if you want to hunt bugs, sharpen your java skills or help with translations, contact us.
]]>Today Tim Berners-Lee pointed me to this headline in the Times Online: "Google could be superseded, says web inventor." This, in turn, has morphed into more ominous restatements in the blogosphere, including "Berners Lee predicts future eclipse of Google."
I spoke with Tim about the interview. Tim was asked "What will be the killer app of the Semantic Web?" A part of his reply was that text search is not necessarily the killer app for the Web of data. That is, while text search is important when searching among a Web of documents, there are other forms of query more suited to a Web of data (cf. W3C's SPARQL Recommendation). The comment seems to have been seriously distorted on its way to a headline.
Because of the importance of vendor-neutrality to his role as W3C Director, Tim does not go about publicly predicting the demise of this or that company. In fact, Tim made clear to the reporter that he does not make statements about specific companies. Thus, reading "Google" in the headline came as a big surprise.
If next week you read that Tim has predicted the demise of a different company, please check back here.
]]>