Recently, a project came up which had a particularly difficult requirement included. Pharma industry sites have a pretty tight set of restrictions to start with but some things take it to a new level. One of these is the so-called “Black Box Warning” that some drugs must display. Essentially, a black box warning is a warning of extremely risky side-effects that a drug might have, such as death or the danger of suicide which a certain class of drugs pose for teens.

Offline, these side effects must be highlighted on the prescribing information documents within a box with a thick, black border (hence the name). Online, a similar callout must appear on every page of the site. However, the size of the warning can be significant, creating a difficult situation to fit it into a design – particularly since it’s mandated that the warning must appear above the fold on an 800 x 600 pixel screen.

Our First Solution

We had originally come up with a solution to create a significant call-out which then linked to an anchor further down the page. The callout would sit above the fold – fulfilling that regulation – but we would have the majority of the text lower to preserve the design. Then the client came back and added another qualification – they wanted ALL of the content above the fold. We solved that fairly easily by using an iframe to contain the full paragraphs with only a few lines visible at a time, but allowing the user to scroll through the whole thing. It wasn’t pretty, but we were able to work around it.

A New Wrinkle

Then the client upped the ante further – now they wanted it to stay in the user’s view at all times. That is, they wanted the warning to scroll with the user as they moved down the page. The found an example that they liked which used DHTML to carry a frame at the base of the page and scroll it back into view as the user scrolled.

Aside from being annoying, this method presented numerous usability and accessibility problems. Among the problems:

1. The scrolling feature didn’t work without JavaScript enabled
2. The scrolling frame didn’t print
3. If users turned off CSS, the whole frame moved to the bottom of the page
4. The whole script didn’t work in IE5.5
5. Screen readers couldn’t ‘see’ the text to display it
6. Popup blockers were sometimes interfering with the display of the box
7. The users could not get rid of the box or warning
8. The box didn’t resize with the browser, creating horizontal scrollbars on smaller screens/browser windows

A few of these problems were Level 1 usability failings – i.e. they would literally affect the ability of the user to interact with the content (in most cases preventing it). Primary among these Level 1 failures was the fact that we were conveying information that some individuals would not be able to see, particularly those with assistive technologies. Items such as the scrollbars and popup blockers weren’t as critical but were still UX failures in general because of the bad experience they perpetuated.

For example, users who didn’t have JavaScript enabled (10-20% of users, based on industry estimates), were given the Black Box Warning in an iframe instead of a floating frame. I would think this was a more preferable method myself, since I felt that the auto-scrolling frame was more annoying and distracting, but it didn’t meet the “always in view requirement”. Worse was that scrolling frame itself – as the user scrolled, the screen would pause and then the warning would ‘bob’ back up into view at the base of the screen. Aside from the annoying action it created, it was constantly covering content – the initial view of the content (“above the fold” was 35-40% hidden by this frame, and at the bottom of the page the user had to go to the bottom, wait for the box and then scroll again to be able to read the content at the bottom of the page.

Similarly, not having CSS turned on threw that frame all the way at the bottom of the page – although some of that was a function of the design not being 100% functional sans CSS (it was a legacy design we were updating).

Other concerns quickly surfaced as I learned the limits of this method. We expressed to the client that we would prefer to use another method entirely because of the impact on a portion of the audience, but they were insistent. So, I went about coming up with a way to a) make it function better and b) reduce the impact on users who were using alternative methods or weren’t using the absolute best browser/size combination.

What to do, what to do…

After some research and thinking, we came up with a solution – or rather, set of solutions – that would address nearly all of the concerns we had. Even better, the fixes were simple to accomplish.

First, we summarized the concerns:

Then we set about fixing them. For #1, we used a hack because it was the quickest and easiest way (we were on a time constraint) – because IE takes advantage of conditional statements, we used one to set up a different set of code for IE5.5 and earlier using .

Solving for 2-5 became a simple exercise once I noted one thing – almost all of this could be compensated for using CSS stylesheets and a noscript tag. First, we created a section within the noscript that would display in the event of a lack of JavaScript to better the visual effect of the code (this wasn’t strictly necessary since there was content showing even without JavaScript – however, the end solution made it look and function slightly better).

Then we created a duplicate of the text from the current code in a new div which was given a class of “blackbox”. This is where the stylesheets came into play and solved #3, 4 and 5 quickly. Using the same code in all three stylesheets (I would have preferred to reference the changes via import instead, but there were concerns about cross-browser viability), we then changed how the code would be seen depending on the media.

MEDIA: CSS (well, the display portion, at least)
SCREEN: .blackbox {display:none;}
AURAL: .blackbox {display:block;}
PRINT: .blackbox {display:block;}

By doing it this way, we had the true text of the warning in the markup, but hidden from view on screen – unless the user didn’t have CSS enabled, in which case, the CSS hiding it would be ignored and the text would be visible. Granted with no CSS but with JavaScript enabled, they would see it twice, but we figured the incidence of that happening among our user base would be approaching zero.

The aural and print stylesheets, however, WOULD render the text in the appropriate spot – the same spot that it was absent using the JavaScript alone.

Conclusion

This solution was a good, solid approach to making a less than optimal programming requirement work the best for as many people as we could. We started with a bit of programming that was chosen mostly on ‘wow factor’ but lacked basic usability and accessibility and made sure that we were able to make it usable for a wider spectrum of users. It still wasn’t perfect – the scrolling feature in and of itself is not a popular feature – but ‘annoyance’ is not a usability/accessibility failure, technically (well, maybe usability-wise it is).

Ironically, in the end this solution wasn’t used – because the client agreed with our original assessment that the scrolling part ended up being such a negative user experience that it would actually hinder and annoy the very people they were trying to inform. The final solution used a emphatic call-out that linked to the full text at the bottom of the page, and ended up being sufficient to meet FDA and client regulations.

But I still found this exercise to be a good example of how, when presented with a less than optimal starting experience, diligence and creative thinking can come up with a solution that addresses client needs and provides for usability and accessibility at the same time.

Decidedly NOT about Black Box Warnings

• A Greener Apple – via Airbag

This entry was posted on Friday, May 4th, 2007 at 2:55 am and is filed under Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.