Alt Text on the Picture Element?

This is one of those posts that might interest only a few people and even then only if you are interested in a very specific aspect of this ongoing standard development.

Yesterday I got into a conversation (just one of the messages) on the W3C Responsive Image Community Group mailing list about the alt attribute on the new picture element (see the W3C Editor's Draft). For those who don't know, this community group has been working on producing a method in HTML to allow web developers to specify multiple sources for an image in the same way that we use media queries to specify a particular set of CSS styles to apply to a page.

The discussion was focused on accessibility for the picture element. One suggestion was to use an ARIA role on the picture element to point back to the fallback img. The other suggestion was to just replicate the fallback img's alt text in an alt attribute on the picture itself.

In the end, Mathew Marquis, who is the group chair, proposed these two options:

1. Duplicating the alt attribute on both the picture element and its fallback img;


2. Only specify alt on the fallback img, using aria-labelledby on its parent picture to reference the ID of the fallback img.

Here's the problem—only three people from the community group have responded so far, me being one of them. More responses are needed on issues like this. The broad strokes are in place, but the details are what can kill a specification (or a project, or a patient, or a credit rating). If you are a part of the W3C Responsive Image Community Group (and are reading this and care about these issues) then now would be a good time to pop your head up so others can hear.

In case you are curious, here is my take (which a year from now I may find was an awful idea)…

I think alt on the fallback img should be required and explicitly spelled out as such.

To build on that, I feel that it will be easier for authors and toolmakers to just require the alt on the fallback img, but not on picture. Let picture rely on the fallback img's alt as a single place for fallback content (essentially dump alt from picture altogether).

Then there is no need to worry about duplicating alt to picture and we can lean on existing alt rules, expectations, and even tool implementations even as this new element gets traction.

The two other respondents have far more practical experience with the specifications and accessibility in general, so you should read what Laura Carlson and Bruce Lawson have to say on this. Steve Faulkner has also weighed in, indirectly, on the HTML Working Group mailing list.

And then you can weigh in with your own thoughts. I'd like to see a responsive image solution, whether this one that is proposed or another. Only pushing for something, either way, will make that happen.

Bear in mind, even if this spec doesn't make it and another solution comes forward (server-side or even image-format-based), these conversations help inform other options. This ultimately helps end users, so it's a good idea to get involved. Bruce Lawson helps put a little context around this whole discussion in a post from yesterday, On the publication of Editor’s draft of the picture element.

Almost Related

• Image alt Attributes Not Always Required in HTML5, April 19, 2011.


• More on Image alt Requirement in HTML5, May 2, 2011.


• Image alt Exception Change Re-Re-Requested, June 11, 2012.

Read More

CSS Background Images & High Contrast Mode

I try to stay up on accessibility gotchas and weird browser implementations, but I just discovered one that I suspect I should have already known.

In Steve Faulkner's post, Notes on accessible CSS image sprites, he tosses out a factoid that was new to me:

When high contrast mode is enabled in the Windows OS, the sprite is not displayed (CSS background images are not displayed in high contrast mode).

This statement is made in a larger discussion of how to create appropriate fall-backs for designs that rely on CSS image sprites. He provides some handy scripts and techniques within the article.

Separately from this I saw a post yesterday on one of the Microsoft blogs titled -ms-high-contrast media feature that discusses a media query for Windows 8 and IE10 that will detect if the viewer is using high contrast mode (and which flavor).

The code is pretty simple and uses an -ms prefix to do its work:

@media screen and (-ms-high-contrast: active) {/* All high contrast styling rules */}
@media screen and (-ms-high-contrast: black-on-white) {
    div { background-image: url('image-bw.png'); }
}
@media screen and (-ms-high-contrast: white-on-black) {
    div { background-image: url('image-wb.png'); }
}

Clearly this isn't ready for prime time, and you'll still need to use techniques outlined in Faulkner's post, but it is a handy technique that I hope makes it into the spec and gets support from other operating systems and browsers.

Granted, web devs may still screw it up (as they have with accessibility and/or print styles for years now), but at least those worth their salt (and rates) will have another tool to better support users in various configurations.

Related

• Techniques for High-Contrast-Friendly Icons

Update: November 8, 2013

With coming support for the luminosity media query in CSS4, perhaps you can re-use some of your work for high contrast mode or vice versa: Responding to environmental lighting with CSS Media Queries Level 4

Read More

CSS-only Radial Menu Experiments

I have been working on a slow and plodding redesign of my personal site and am playing around with some navigation ideas.

I wanted to create a JavaScript-free and image-free radial menu, an idea I toyed with a couple years ago and abandoned due to the lack of CSS support to do what I wanted in current browsers at the time. I decided to give it another shot last weekend while recovering from being pleasant for two days.

If you aren't familiar with radial menus or are curious about why they are popping up as a topic lately, check out Josh Clark's Touch Means a Renaissance for Radial Menus. You can expect to see them more as Windows 8 is released in a couple months.

I threw together a simple five item navigation list, attached no classes or IDs, and decided to see how far I could get before it became untenable (or I got bored).

Single Level CSS-only Radial Menu

.html {
  background-color: #6D695C;
  background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAMAAAAoLQ9TAAAACVBMVEUAAAAAAAAAAACDY+nAAAAAA3RSTlMmDQBzGIDBAAAAG0lEQVR42uXIIQEAAADCMHj/0NdkQMws0HEeAqvwAUGJthrXAAAAAElFTkSuQmCC); }

body{
  margin: 0;
  font-family: Arial, Helvetica, sans-serif;
  /*font-size: 2.5em;*/ }

nav {
  width: 5em;
  height: 8em;
  float: right;
  padding: 0;
  overflow: hidden; }

nav:hover {
  background-color: rgba(0, 0, 0, 0.4);
  width: 16em;
  height: 15em;
  border-radius: 0 0 0 15em; }

body {
  background-color: #eee; }

nav h1 {
  position: relative;
  top: -.75em;
  right: -.5em;
  margin: 0;
  background-color: #000;
  color: #000;
  z-index: 1;
  font-size: 2em;
  line-height: 100%;
  width: 1em;
  padding: 1em .5em 1.25em 1em;
  border-radius: 3.0em 0 0 3.0em;
  -webkit-transform: rotate(-45deg);
  -moz-transform: rotate(-45deg);
  -ms-transform: rotate(-45deg);
  -o-transform: rotate(-45deg);
  transform: rotate(-45deg);
  overflow: hidden; }

nav h1::before {
  content: "\AB";/*« «*/
  /*content: "\21D0";*//*⇐ ⇐*/
  color: #fff;
  -webkit-transform: rotate(-45deg);
  transform: rotate(-45deg); }

nav:hover h1 {
  display: none; }

nav ol {
  margin: 0;
  padding: 0;
  list-style-type: none; }

a {
  display: block;
  position: absolute;
  top: -10em;
  right: 0em;
  border-radius: 4em;
  border: .15em solid #fff;
  padding: 1.5em 0;
  width: 4.5em;
  text-align: center;
  box-shadow: .45em 0 1.5em rgba(50, 50, 50, 0.75);
  -webkit-transition: all 0.2s ease-in;
  -moz-transition: all 0.2s ease-in;
  -ms-transition: all 0.2s ease-in;
  -o-transition: all 0.2s ease-in;
  transition: all 0.2s ease-in; }

nav:hover a {
  /*display: block;*/ }

a:link, a:hover, a:focus, a:active, a:visited {
  text-decoration: none;
  color: #ddd;
  background-color: #000; }

a:hover, a:focus, a:active {
  background-color: #222;
  color: #fff;
  text-shadow: 0em 0em 0.2em rgba(255, 255, 255, 0.8);}

nav:hover li:nth-child(1) a {
  right: 13.5em;
  top: .2em; }

nav:hover li:nth-child(2) a {
  right: 12em;
  top: 4.75em; }

nav:hover li:nth-child(3) a {
  right: 9.0em;
  top: 8.5em; }

nav:hover li:nth-child(4) a {
  right: 4.75em;
  top: 11em; }

nav:hover li:nth-child(5) a {
  right: 0;
  top: 12em; }Check out this Pen!

View this directly on the Codepen site.

Note the style for the body. If you uncomment the style /*font-size: 2.5em;*/, you will see that entire menu scales up. You can put any text size in there you want and the menu will scale up and down. All the sizing (text, borders, positioning, padding, etc.) is based off ems, which makes it easier to scale each part of the menu proportionally.

You may note that I put an onclick = "void(0);" on the h1. Without this, the menu just wouldn't work on iOS. Otherwise I am relying on my Android devices to read a touch as a hover.

You may also see that there is an image on the page. This is a striped background that made it easier for me to see where elements aligned. It is not used in the menu itself, but I do like how it looks so I kept it.

I opted for CSS positioning changes instead of CSS animations since the support is consistent. The menu works in IE9, though without animations. Since the menu uses HTML5 elements, and since it is an experiment, I am not testing older than IE9 (yet).

Then I was curious how hard it would be to add another level into the menu and how it would feel as a user…

Two Level CSS-only Radial Menu

<!-- Original pen (~July 2012) lost by CodePen, this is a recreation with their assistance to get the old code. -->
<nav role="navigation">
  <h1 onclick = "void(0);">Menu</h1>
  <ol>
    <li><a href="#">Bio</a>
      <ol onclick = "void(0);">
        <li><a href="#">Bio One</a></li>
        <li><a href="#">Bio Two</a></li>
        <li><a href="#">Bio 3</a></li>
      </ol>
    </li>
    <li><a href="#">Blog</a></li>
    <li><a href="#">Books</a></li>
    <li><a href="#">Articles</a></li>
    <li><a href="#">Contact</a></li>
   </ol>
</nav>

<!--
The onclick attributes are to allow Safari on iOS to see these otherwise non-clickable elements as clickable so it can then apply the hover styles as if they were clicks.
-->
Check out this Pen!

View this directly on the Codepen site.

I forked the single-level menu and put another level under the first item ("Bio"). With only three items it was still time consuming to style the positioning of elements and get the animation look that I wanted.

I also had to put an onclick = "void(0);" into the nested ol in order for iOS to recognize it as a clickable element. Sadly, that means that "Bio 3" always gets the focus on touch devices because it's at the top of the stack when the focus is applied through a tap.

On desktop browsers however, it works well.

Wrap-up

Drawbacks for both of these menus are many. For example, using my positioning method it can be very hard to calculate where additional menus should appear, making this tedious to code into a CMS. The menu items also all rely on very short navigation text in order to fit into the almost-circular navigation items. The collective shadows from nested items make for an interesting shadow stack obscuring subsequent menu items.

However, given the real-life feedback I've gotten I figured there might be some ideas or code chunks others might find useful. Even better would be if someone gets inspired to take this to the next level and clean it up, fixing my own shorthand tricks and making it more robust.

Corrections, suggestions, feedback, and forking are all welcome.

Read More

Age, Treachery Bests Youth, Skill

Social Media seems to be wildly misunderstood by some folks, including those within the social media profession who have the ability to use its own tools to spread that misunderstanding like a telephone game.

Though my example is old news (by SM standards), I have seen it popping up for the past couple weeks pretty regularly. On July 20, Nextgen Journal published a piece called Why Every Social Media Manager Should Be Under 25.

I should qualify that when I heard the title I laughed and assumed it was parody. It wasn't. By the time I read her piece (two days after it was posted) a series of blog responses had popped up. I tweeted the absurdity from a conference (I was studying web intents, really):

Hah! "Why Every Social Media Manager Should Be Under 25" nextgenjournal.com/2012/07/why-ev… Response: experiencetheblog.com/2012/07/a-resp… via @blairboone cc @smcbuffalo

— Adrian Roselli (@aardrian) July 23, 2012

I could easily pull the article apart, but it's been done. The link in my tweet does a good job already. To the young author's credit (which may demonstrate that she does understand social media), she has avoided the Streisand effect by allowing the article to stand and the comments to roll in.

Instead of reading all the rebuttals, I like the meta conversations that have popped up about the concerns over ageism in the industry (which appear to be so far unfounded by the successful brands), or how we should all remember that once it's on the internet, it tends to stay (something older users may have been protected from in college, though I wasn't one of them). Some have even suggested the responses from the elder generation could have been more helpful and less brutal (even if I think some of the brutality was helpful).

Some folks saw an opportunity and just ran with it, like the guy who registered CathrynSloane.com, the name of the author of the original article:

I discovered Cathryn had decided not to secure her personal domain name for the past 10 years […] I spent a total of $11.00 USD and about an hour setting up free email & web hosting for this domain. Now all 2,267,233,742 (as of 12/31/11) Internet users can find and read the information presented here. No need to mess with Facebook, Twitter, etc., and I have full informational control over content/context and privacy.

I am over 25. Not by a little. I am also a member of the local chapter of Social Media Club, whose local membership spans a range of ages but does tend toward the younger (than me) side.

I have clients who have asked about finding someone to help them act as their face on assorted social media platforms. I tell them that factors to consider when evaluating a social media manager include experience, skill, understanding the brand message, and just having the emotional intelligence and savvy to present a brand on any social media outlet.

An intern at the copier may be a great use of an inexpensive resource, but an intern who acts as the voice of your organization in a particular form of media probably isn't. Knowing how to use a copier is a rote skill which does not make an intern qualified to produce the annual report or press releases. I feel you can swap Facebook, Twitter, etc. in place of the copier and the analogy stands.

I'd also like to point out that much of this is a rehash of conversations back at the dawn of the web, when the job title "webmaster" was coined and the younger someone was the more qualified he/she was. That also didn't pan out as true.

No matter how old you are, there is something to be learned from this entire story. Probably many somethings, but one that stuck out during a conversation today (which led to this post) was that knowing how to use a tool doesn't mean you won't cut yourself with it. I suspect Ms. Sloane has learned that now.

Related (Because I Said So)

1. Another Piece Claiming Social Media Makes You Dumber, August 9, 2011.


2. Twitter As Passive-Aggressive Enabler, January 4, 2011.


3. Humorous Social Media Infographics, October 6, 2010.


4. Don't Let Social Media Get You Robbed (or Stalked), March 2, 2010.


5. Lots of Twitter Followers Guarantees... Nothing, January 6, 2010.


6. Facebook Doesn't Make You Smarter, Rigorous Research Does, September 8, 2009.

Read More