One word that comes to mind when I think of today’s guest star, Faruk Ateş, is passion. Anyone familiar with his Twitter account or blog might find, from time to time, passionate zeal about many things. Including Apple.

I’m not convinced a company sitting on dozens of billions of dollars of cash needs apologists. I’ve got it on good authority that they’re doing OK. But that doesn’t stop Apple fans (which today Faruk is representing) from swarming to the company’s defense at a whiff of criticism.

So I’ll clinch my butt cheeks tightly as I proceed to criticize.

The iPhone 5 is out. Along with it came iOS 6. And along with that came some interesting software changes. To put it mildly.

Let’s clear things out first. The iPhone 5 is a great, top of the line, modern phone. It’s an unbelievably light and thin piece of gossamer and wonder that represents just how crazy technology is these days. I’m not daring to imply otherwise.

But despite that, it’s also something of a catch-up phone. With the exception perhaps of its surprisingly lightweight and thin physique for a phone with its feature-set, the phone isn’t exactly sporting anything revolutionary. Yes, Tim Cook made it a point to tell us how awesome it is, really pumping it up. Which he should, because that’s his job. But he may have overstated how unprecedented the iPhone’s many new… for it… features are.

Does that make it a bad phone? Heavens, no. It’s a thoroughly impressive, gorgeous, modern phone. But it’s now part of a pack of modern phones with comparable feature sets.

Which is great. I like healthy competition.

What is less great is a few changes to the software that phone (and other iPhones, like my own 4S, that have been updated to iOS 6) have brought upon us.

Exhibit A: the new iOS Maps.

There’s probably a great reason they decided to replace Google Maps with their own self-made app. I’m thinking it involves buckets of cash and super-valuable user data. Also, it’s no surprise that the honeymoon days between those companies ended about twelve seconds after Android was introduced to the world.

But it’s shocking that Apple, who so carefully crafts experiences as mundane as removing their products from the packaging, dumped such a thoroughly substandard replacement with so many glaring errors upon us.

Dylan and I talk about this in detail during our inaugural Squirrel and Moose podcast, in case you want to hear more on that topic. But in short, it’s disappointing, and it’s not the Apple I’m used to seeing, and I’m glad that at least some of the loyal Apple followers are admitting that this is a misstep.

Because no matter how well you dress it up, a turd is a turd.

Despite how public and loud the dissatisfaction is with iOS Maps, iOS 6 presents us with something far worse that we should be paying more attention to.

That, ladies and gentlemen, is the new App Store. Read that. Please. Take a gander. Heck, if you’ve got an iDevice of some sort, go look at it yourself. Use it. Try to find new stuff. Having problems? Yeah…

This just doesn’t make sense. It’s not helping the users, it’s not helping the third party developers. It’s just bad. If you want to find a new app, and you aren’t specifically looking for something by name, have fun finding anything that isn’t a best-seller.

I’m not sure how this helps Apple, or help the iPhone user experience.

Apple is a big, rich company with lots of smart, talented employees. These missteps, and there’s plenty this time around, are so uncharacteristic that it’s baffling. Especially at a time when the competition is so strong. I’ve had an iPhone for years now, but despite its sparse app landscape I’m beginning to think about picking up a Windows Phone the next time I upgrade. iOS 6 isn’t helping convince me otherwise.

The iPhone 5 is a great phone, an evolutionary device even if it’s not a revolutionary one. It’s sold millions, and will sell millions more. But iOS 6 is a step backwards, a devolution if you will. And if Apple doesn’t double down on fixing their blunder, they’re going to run the risk of simply being one of many great smartphone makers instead of being the great smart phone maker.

[Update: Here's a new post by Jared Spool talking about iOS6 Maps and the opportunity it provides us to show the value of (and need for) investing in quality content in websites and apps.]

It’s true. I pre-ordered Borderlands 2, but thanks to the wonders of shipping delays the game is somewhere between the warehouse and my home. It will be days yet before it makes it into my hands. Part of me wonders at the purpose of pre-ordering something if it’s not shipped in time to be received on launch day, but somehow I’ll survive. Like the Squirrel, I might choose distract myself through the powers of make-believe. Whatever it takes, right?

Don’t let my current game-related obsession fool you, however. I’m not suddenly competing with Penny Arcade for the title of “best gamer comic ever”. Today’s comic actually touches on the field of web design while discussing games for a very specific reason. Today’s guest star is Anna Debenham, a freelance front end developer from Brighton, UK. Anna is one of those brilliant web people that continues to add to that city’s reputation of being stuffed full of an unfair amount of awesome talent.

If somehow you haven’t heard of her yet, you will have a hard time continuing that trend going forward. Among other things she has contributed to 24 ways, shared her wisdom at conferences (she will be speaking at the upcoming Full Frontal 2012), and has just had a very interesting article about testing websites in game console browsers published over at A List Apart.

The article is a good read, and I recommend you check it out because it probably contains wisdom you need but currently lack.

I know I did.

Yes, I already knew that people were browsing websites via consoles. Yes, I knew that in some cases those consoles’ browsers aren’t nearly as capable as a typical desktop experience. But in my head that wasn’t something I needed to worry about. After all, how often are people browsing the web via their PS3?

A lot, it turns out. According to Anna’s article, a full one in eight people overall (in the UK, US and France) and one in four teens use their game console to browse the web on a regular basis. That, my friends, is a lot of people.

It’s an amount we probably can’t afford to ignore.

Among other things, this means that I now need to start thinking about how client sites might look in console browsers. I wonder if I can use this data to get Mindfly to set up an Xbox 360, PS3 and Wii in the studio.

You know, for work purposes.

This also reminds me of the need for community device labs that Jeremy Keith (another Brighton design wizard) has been thumping for. There’s so many bloody web-connected devices these days that it’s outside of the budget of most studios or teams to build a thorough collection themselves. Which is why he advocates the need for designer communities to support each other in putting together an open lab for one another to contribute towards and make use of. In his posts Jeremy spoke mainly about having mobile and tablet devices, but after reading Anna’s article I think there’s good reason to include consoles and even browser-capable toasters in such collections.

Let’s be honest, if a toaster can’t connect to the Internet yet, one soon will.

Should we be designing for every device, including consoles, with our websites? No. That way lies madness. There’s simply too many to account for, and by targeting all the ones you know you’ll be explicitly excluding the ones you don’t.

Nor should we get caught up in the mentality of targeting sites to specific devices. Every time you build a site to render specifically on an iPhone you’re failing to take into account how many other smartphones are out there with different capabilities and screen dimensions. Despite how abundantly clear this is, I see the same mistake made over and over again.

Don’t make your sites for specific devices. Please.

Anna rightly points that out herself in her ALA piece:

We can’t tailor experiences for every possible use case on every device, but we can use what we know about console web browsing to build a better overall experience. Like we’ve done by designing with mobile in mind, considering how a site could be used on a console can have a knock-on effect of making it easier to use overall.

Jeremy Keith speaks to that same point in the article of his that I linked above:

In fact I’ve found that one of the greatest benefits of testing on as many different platforms as possible is that it stops me from straying down the path of device-specific development. When I come across a problem in my testing, my reaction isn’t to think “how can I fix this problem on this particular device?”, which would probably involve throwing more code at it. Instead I think “how can I avoid this problem?” The particular device may have highlighted the issue, but there’s almost always a more fundamental problem to be tackled …and it’s very rarely tackled by throwing more code at it.

So do yourself a favor. Go check out Anna’s article about consoles. If you haven’t already done so, start thinking about what it means to be a web designer in a world where virtually every device we can think of can visit your website, and what it takes to make a design robust enough to survive on them all. And the next time you start thinking about tailoring for specific devices, stop and remember that’s a trap you can’t afford to fall for in our modern device-happy world.

I count myself lucky to know Dylan Wilbanks. He’s an intelligent, well-spoken man who thinks and says things in a way that makes me intensely jealous of his erudite nature. In today’s comic, he witnesses the Squirrel in a hare-brained moment as he embraces his strengths in the wrong way.

Hustle is Hype is a piece written by Dylan that he posted with some trepidation on how it would be received. In it, he presents the radical proposition that we don’t need to work ourselves to death, that “hustle”, the 80 hour workweek that the tech start-up world tells us we need to be great and successful, isn’t a sign of greatness, but weakness.

He dares to suggest, rather outrageously, that we should embrace our strengths and have some focus. That we should work smart instead of blindly working long hours. That if you’re good at something, you should work to be great at it, instead of trying to re-do all the work of the rest of your team.

He even suggests, and I know this is going to disgust you, that we should trust the people we work with. That we shouldn’t be threatened by talent in our co-workers, that we should embrace their skill and encourage them to use it rather than suffocating it .

When it comes down to it, Dylan has the audacity to state that we should dare to live quality lives. He states that we should concentrate on the quality of our talent and skill rather than bleeding out all our time in the office in an quantity-focused 80 hour work week of bleary-minded labor.

Some people are offended by his post, believe it or not. People who may be missing the point of “focus versus hustle”, or who think he’s preaching “specialists versus generalists”. People who don’t get it.

Well, I do get it. I know I’ve had a tendency to burden myself down by overreaching, juggling too many plates, trying to drill down too deeply in too many skill-sets when I’ve got team members that can do the same job better and faster. Basically I’ve frequently burnt myself out instead of giving myself the opportunity to excel at the things that I’m best at.

A real team, in any environment, is one that may have an overlap of skills, where each person can take on another’s tasks if the need exists. But more importantly the team plays to its strengths, making the most use of each person and their skills to the best end results. There’s a great deal of trust involved, when each person in a team takes on what they do best and relies on the others to do their part, letting them do the same.

The kind of trust that pays off.

Stop working yourself to death. Find your strengths, trust your co-workers, and maybe get home while the sun’s still out.

Sounds good to me.

John Foliot reprises the role of the Scarecrow and Matt May takes a turn in the role of the Wizard in today’s Ozian look at the HTML5 Issue of the Week, and represents the frustration I’m sure accessibility experts face every damn day when trying to deal with the nonsense that is getting people to adopt proper accessibility support in the web.

Today we’re looking at ARIA’s role (no pun intended) in HTML5. More accurately, whether ARIA would have a role in HTML5. Now, typically my posts about idiocy involving HTML specs tend to involve Hixie and the WHATWG. This time, sadly, I’m discussing the W3C, and specifically actions of the co-chairs of their HTML WG.

And here I thought we were besties.

I’ll recap:

For entirely too long now the W3C has been debating whether or not to include the longdesc attribute in HTML5. This debate, which has been pretty rancorous since at least 2008 (jinkies!) is known as Issue-30. Longdesc is an attribute that you can attach to an image tag to inform capable devices of looking to a specific URL for a longer description of the image for the visually impaired. We’re not talking about a simple alt tag of “girl under tree” for every college campus in the world. We’re talking about a genuine effort to impart the information about an image to a viewer who can’t properly see the image, if at all.

Here at CSSquirrel I use the longdesc attribute to link to the transcripts for the comics.

To me, this is a big deal. I have blind readers, many of which want to enjoy the comic that the sighted readers can see. I’ve received numerous requests in the past to put transcripts up, so I’ve built the site to serve that need. Is it a sizable percentage of my readership? No. Does that matter? No! If we’re letting lazy implementation of available solutions get in the way of us helping one visitor with accessibility needs, then what does that say about us as people?

During a standoff between the W3C groups responsible for HTML and ARIA, Sam Ruby (Co-Chair of the HTML WG) suggested that the entirety of ARIA be removed from the HTML5 spec until sometime in the future when Issue-30 could be amicably resolved. This is absurd! It’s like throwing the baby out with the bathwater!

There is a lot of ARIA that is seeing author implementation in HTML right now, most notably ARIA roles. Their inclusion provide real assistance for visitors with accessibility issues in navigating and understanding the content of a website, and in some cases provide extra helpers for non-human agents to crawl the content as well. (I’ve even used them as clever hooks for tricky bits of CSS).

A debate ensued.

Well, re-ensued.

At one point, John Foliot dropped in with a detailed examination of statements being made by the HTML Co-Chairs about the situation, correcting falsehoods and reinforcing how important this issue is. This is a man who’s spent years as an accessibility expert watching bureaucratic process and non-expert interference getting in the way of providing solutions to genuine accessibility needs. He gets direct and to the point, as time and again it’s been proven over and over that anything short of that will fail to sink in.

Their detailed response to the situation thus far?

A slap on John’s wrist for his tone.

It’s been a few days since, and that’s as far as it has gone.

I’m sorry blind folks. The bad man’s mean tendency to call them out when they’re being bureaucratically false while defending their indefensible suggestion of removing major accessibility support from HTML5 is more important than your ability to use the 21st century’s most important communication medium.

But that’s OK, I’m sure your seeing-eye dog can navigate websites for you, right?

Steve Faulkner recently tweeted the following to me on the topic (good man, fights hard, really should be put in one of my comics ASAP): “I think the suggestion to move ARIA out of HTML5 was misguided tactic of the chairs to force progress on an issue. - won’t happen“

I appreciate that Issue-30, which has gone unresolved for years, is annoying. But threatening to pull out the entirety of ARIA from HTML5 in some sort of chicken head-on-collision maneuver is a new low in the entire HTML5 spec authoring process.

And that is saying a lot.

Are you an accessibility expert or a web developer that uses ARIA? Are you a person with an opinion about longdesc or ARIA roles? What do you think of this whole mess? What suggestions do you have for the W3C to get this mess fixed? Did I get something wrong? Please help educate me by responding via one of the methods below?

Today’s comic features Mat “Wilto” Marquis (Internet folk hero) in a nightmarish world that I imagine Ian Hickson envisions if HTML were ever allowed to slip from his hands and be created by the common man.

We’ve discussed the issue of responsive images in HTML and the proposed <picture> element before, you and I. Here’s a look back in case you need a refresher. It’s a bit cheeky. I get worked up over things like one smart person thinking his brain is more efficient than the combined powers of dozens of smart people.

<Picture> has had a rough road.

All the way back in December 2011, Bruce Lawson posted this idea for how the syntax of <picture> might work. Several people started a community group chaired by Mat Marquis back in February (based on a WHATWG email suggesting such) to push the idea forward so it could see eventual adoption into the HTML spec. They did a great deal of good work to make a workable, problem-solving piece of markup. Scott Jehl even created a polyfill script to provide support for the proposed markup until browsers implemented it, which you can find here.

Then Hixie stepped in. It’s been well documented in the past before, so I’ll summarize: he decided to ignore the community group and efforts of the developer community and went with srcset. Classic Hixie solo action. Here’s an aptly named summary, WTFWG by Tim Kadlec, and a piece on A List Apart by Mat Marquis.

Developers were mad. Developers were vocal. Then for the most part, the web moved on.

If it wasn’t for the continued effort over the past several months of people like Mat, that would have been that. But he and others didn’t stop, and they kept on pushing, and wouldn’t you know it? Something came of it.

Not in the WHATWG, of course. Someone hoping for that sort of miracle would be essentially signaling to everyone that they finally lost their last marble. (Here’s an example of how things were going over there, AKA, Hixie’s got his blinders on like normal.)

But over at the W3C, Mat and his allies accomplished this: an official w3C Editor’s Draft of a proposal for HTML Responsive Images Extension, featuring both srcset AND <picture> to be included into the HTML5 spec. It’s just a step, but it’s a fairly big one, and a great deal of validation for the developers that worked so hard, despite Hixie’s best attempts at ignoring them, to create a responsive image solution that works for them.

I could tell you how it’s a heroic accomplishment that is leading us towards a better web. But I won’t. Not because I think it isn’t (it in fact is!) but because Marc Drummond already said it better. Go read his article Responsive images, the picture element and the W3C: This is how you deal with Hixie and WHATWG. It’s worth it.

It’s hard to say if <picture> will ever make it into the browsers. The browser makers are mostly (but not entirely) involved in WHATWG, and would prefer to work around the W3C. But I do believe that enough community effort will continue to build on the success that Mat and the others have brought us.

I asked Mat about what he saw as the future of <picture> in light of these recent accomplishments, and what interested developers should do to help. Here’s his response.

I totally stand by that follow-up tweet I posted earlier ( http://twitter.com/wilto/statuses/240486846801514498 ): no matter how things play out from here, the dev community has done something that I don’t believe has ever been done before. You just don’t see specs - proposed or otherwise - with a developer’s name at the top. If nothing else I hope this marks the beginning of that, and that it leads to we authors having a voice in web standards equaling that of the vendors.

To get involved, more folks should join up with the RICG! http://www.w3.org/community/account/request

Let’s not waste the opportunity this has given us. We’re the developers that will have to work with the spec that’s being created, and will be answerable to the clients and site visitors that will use the sites we create. We should and can have a bigger voice in the direction of HTML. What Mat and others have done is show us how.