When you build websites that rely on cookies and they are expected to work with privacy settings other than default, you’ll have to deal with P3P. Read on to find out about the cornerstones of the Platform for Privacy Preferences, and get your hands dirty with an example guiding you from empty hands to a complete basic implementation.
The World Wide Web Consortium (W3C), along with other groups and standards bodies, has established technologies for creating and interpreting web-based content. These technologies, which we call 'web standards', are carefully designed to deliver the greatest benefits to the greatest number of web users while ensuring the long-term viability of any document published on the Web. Designing and building with these standards simplifies and lowers the cost of production, while delivering sites that are accessible to more people and more types of Internet devices. Sites developed along these lines will continue to function correctly as traditional desktop browsers evolve, and as new Internet devices come to market.
Accessibility is one of the fundamentals of the Web, so how people who claim to be passionate about the Web and say that they deliver high quality can choose to ignore it is beyond me.
Web developers interested in accessibility issues often look to WAI-ARIA to bridge the accessibility gap created by ubiquitous scripting and make web applications more accessible to blind and visually impaired users. But can we recommend WAI-ARIA without reservation? Are there times when appropriate semantic HTML elements are preferable to custom widgets?
It's been a long trip, but we’re almost out of the dark. We finally have browsers that offer substantial support for several technologies established by the World Wide Web Consortium (W3C) and other standards bodies. Designers and developers can use many core features of XHTML and CSS and sometimes DHTML without worrying about the hazards of cross–browser chicanery. As browsers have evolved, it’s become easier to comply with the W3C’s Web Accessibility initiative (WAI) and, in the United States, with the amendments to Section 508 of the Rehabilitation Act of 1974 (commonly called “Section 508”).
I fully acknowledge that a whole lot of very clever thinking went into the construction of Acid3 (as was true of Acid2), and that a lot of very smart people have worked very hard to pass it. Congratulations all around, really. I just can’t help feeling like some broader and more important point has been missed.
It is six months since the release of WCAG 2.0 and I thought it might be interesting to see how extensively it has been adopted as a bench mark for determining web content accessibility. Over this time, I have felt that the rate of adoption has been relatively slow and the number of countries and other regulatory authorities now using WCAG 2 is lower than I expected.
It has become evident to me that some of my previous comments about HTML 5 and what is going on in the HTML Working Group are the result of misunderstanding and overreacting on my part. I no longer think things are quite as bad.
I find that many designers give much more of their time to learning the latest standards trick than learning the latest “designing for users” trick. Here are a few reasons why this may be so.
The adhoc way in which much of the web was developed has created a dilemma for web designers: should websites comply with standards, ensuring accessibility, or break the rules and work with older browsers? At this moment, the answer is simple: Websites should work with older browsers.
Now that the release of ARIA is approaching, let’s take a look at how ARIA fits within progressive enhancement strategy. Can we use ARIA in a way that respects progressive enhancement? Can we use ARIA in ways that ensure we have a working solution at every level?
It was just two years ago that Microsoft’s Internet Explorer web browser controlled 67 percent of the worldwide market, according to data from web analytics company StatCounter. It has been all downhill from there. According to the the latest data from the company, last month, September 2010, marked the first time IE fell below the 50 percent share mark in the past decade.
Managing flow content can get unwieldy—too many class selectors can become a specificity headache, nested styling can get redundant, and content editors don’t always understand the presentational markup. Heydon Pickering offers an unexpected option for handling cascading styles more efficiently: a variation on the universal selector.
Building designs with CSS is no longer a fringe activity practiced by standards geeks and early-adopters. Creative pioneers and highly skilled designers are bringing CSS to the mainstream. The explosion in popularity is ushering in a new wave of possibilities for web design. CSS provides greater design control, allows more flexibility, and enables sites to become attractive, accessible, and faster-loading, all at the same time.
The web as we know and build it has primarily been accessed from the desktop. That is about to change. The ITU predicts that in the next 18–24 months, mobile devices will overtake PCs as the most popular way to access the web. If these predictions come true, very soon the web—and its users—will be mostly mobile. Even designers who embrace this change can find it confusing. One problem is that we still consider the mobile web a separate thing. Stephanie Rieger of futurefriend.ly and the W3C presents principles to understand and design for a new normal, in which users are channel agnostic, devices are plentiful, standards are fleeting, mobile use doesn’t necessarily mean “hide the desktop version,” and every byte counts.
The layout of your code can really affect how fast your project happens, and whether or not you meet deadlines. On top of that it can also determine how easy it is to read and edit later on, when you’re making alterations to it. That’s why it’s important to follow some of these best practices on how to successfully code a neat website.
Progress always comes at a cost. In the case of web browsers, users bear the cost when developers take the rendering of certain authoring tools and browsers (especially Internet Explorer) as gospel. We could spend hours explaining why our sites broke, but wouldn’t it be better if they didn’t break in the first place?
One of the biggest pains about making Web pages is having to keep track of which browsers support what features. Wouldn't it be nice if there were some way to keep track of it all? Well, we've whipped up a few articles and charts to make things easier for you.
Some browsers have difficulty upon encountering the XML Prolog. In some cases, the browser will render all the markup as text. In other cases, when a browser has some XML support, it might attempt to render the document as an XML tree. To avoid these problems, many practicing web professionals prefer to leave the prolog off. This table will help you make that decision by showing you which browsers have known problems with the XML prolog.
Depending on who you ask, HTML 5 is either the next important step toward creating a more semantic web or a disaster that’s going to trap the web in yet another set of incomplete tags and markup soup. The problem with both sides of the argument is that very few sites are using HTML 5 in the wild, so the theoretical solutions to its perceived problems remain largely untested. That said, it isn’t hard to see both the benefits and potential hang-ups with the next generation of web markup tools.