Web designers and developers are often heard to pour vitriol in the direction of Internet Explorer. I personally find myself cursing its name perhaps once a week. It's always difficult to believe this is a product Microsoft is still trying to promote.
Contemporary GUI development toolkits require an HTML rendering component: Java has javax.swing.JEditorPane; KDE has KHTML; Gtk has GtkHTML. MFC and .NET have Internet Explorer. In this task it is arguably successful: despite being too heavyweight, buggy, and non-portable, it is at least fast and very simple to embed. The applications which use Internet Explorer tend to use it in restricted circumstances so that the largest class of failings – how it measures up to the wild wild web – are not encountered.
With Firefox 3 right around the corner and a total radio silence on a potential IE8, it's worth considering how much Microsoft has to do to maintain its web browser's competitiveness.
Most mistakes web designers make stem from the assumption that the way they are seeing the site in their web browser is the way everyone else sees it. By using uncommon defaults in your web browser, you can ensure that you have left to the default only those aspects of a page which you had intended. I call this "misconfiguring" because it is intentionally configuring a web browser to display pages wrongly. If the page looks correct with such settings it is probable nothing has been left to chance.
It is common practice to test a web site in various web browsers, but this testing can give a false impression of the compatibility regarding different default settings. This is because almost all browsers have settled on a common out-of-the-box set of defaults. The user is allowed to override these defaults. Fail to anticipate this and your website risks visual problems for some users (perhaps 1% or so, to take a wild guess). Problems include:
Character set issues, such as £ or the opposite, a broken character symbol (the question mark diamond in Firefox) rather than £.
Specifying a font colour but not a background colour, causing clashes or even invisible text. Perhaps 10% of websites fail to specify a page background colour but assume that it will default to white.
Linking images which are intended to composite onto white. This looks dreadful onto most other colours.
Copy looking illegible due to tiny serif fonts (sans-serif is more legible on low-resolution screens).
Body font clashing with image-based buttons and titles: serif and sans-serif fonts rarely mix.
Pale-coloured boxouts. What appears pale is in fact a function of the background colour. A light pink box appears pale on a white background, but very bright on a black background, for which the corresponding effect would be a dark red box.
The browser defaults which you may want to change include
Character set
Background colour
Text colour
Font style
Font size, although in theory you should avoid specifying this for accessibility reasons.
Misconfiguring a web browser is an art. It is perfectly acceptable to use the defaults a user specifies, as long as all of them are respected. While you should feel free to wholly b0rk a browser which you use purely for testing, it is more beneficial to misconfigure the web browser that you use for primary development. For me, this is the same web browser that I use for everything else, Firefox. Therefore the misconfiguration has to be something that isn't wholly unusable to me. More importantly, the new defaults have to be ones that I would be unlikely to use for a website, otherwise I could still rely on my defaults.
Because I tend to use sans-serif fonts, white backgrounds and black, grey or blue text, and UTF-8 character set, my browser is set to default to serif, coppery-orange text on a mid-grey background. I'm experimenting with ISO-8859-11 (Thai) as my default character set, because this isn't compatible with UTF-8 nor ISO-8859-15 for the most common problem area: £ and € symbols. It is compatible for ASCII-range symbols, so try UTF-16 if you are aiming for perfect incompatibility. I don't specify font-size but I Ctrl-roll my mousewheel on occasion to watch how the site changes at different font sizes.
So my default browser settings look like this. If I ever see these styles on a page, I know I've failed to specify something.
For most of us, visualising date and time comes very naturally. I'm sure if we surveyed how people visualise date and time there would be some similarity among a plethora of different answers. However, one form stands alone for its ubiquity: a year-planner-style calendar. Twelve grids of numbers, each seven columns wide, four to six rows deep. Click on a number to do something with that date.
Calendars are so simple for me and – statistically – you that it's easy to forget that a server-generated calendar like this is actually not accessible at all. The issue here is linearisation: flattening out the days of the calendar to a script that can be read – aloud, in braille… or by a search engine. A calendar in this form linearises to a script that reads like this:
And so on. It's not useful to read out 365 numbers (366 next year) and expect users to just wait to respond when the day of the year they are looking for comes up.
What is the accessible version? Well, the approach to take is to work out the linearisation we would like first. For example,
The following periods are currently available: the fifteenth of October to the twenty-ninth of November, then the eleventh of December to the seventeenth. Which date are you interested in?
Now, for a web page we might not expect to follow this pattern exactly, but the model is clear: list the calendar information, then query for a date. It looks something like this:
Periods Available
15th October – 29th November
11th – 17th December
This is not bad even in a graphical user agent; describing calendars as schedules is not hard to visualise. Note that it would be perfectly possible to use Javascript to convert this calendar to a visual representation. Whether using Javascript in this way is accessible is open to debate. There is no reason screen readers can't execute Javascript. Some, I believe, already do. But there is a trend for graphical browsers to provide Javascript and for non-graphical browsers not to.
I'd suggest if you are willing to forgo an approach that caters ideally to non-visual users, it's possible to do better. We can cheat the system, almost, by using alt attributes in images and image maps to provide the schedule version as above, but for the images and maps to supply the visual layout. In my latest project, I'm also using line boxes full of images rather than a table. This allows a single <a> tag to span a whole month worth of dates. But what it saves on the semantics, it loses on file size. A cheaper approach might be client-side image maps, especially of the lesser-known form involving <a shape=""> tags rather than <area shape=""> elements, or similar features in SVG.
However, even with the approaches I've explored above, this is one area where I suspect there may not be a very solution that does equally well for visual and non-visual users. 365 dates worth of information is difficult to represent in a concise form. That's why we use calendars.
In a previous post I discussed the method I used to integrate Paypal's Encrypted Web Payments in generic SSL terms I hoped would make it easy to implement from scratch in any language. I've had a request from Ross Poulton to share the Python code that makes it work using the M2Crypto wrapper. So, here it is:
from M2Crypto import BIO, SMIME, X509
from django.confimport settings
class PaypalOrder(dict):
"""Acts as a dictionary which can be encrypted to Paypal's EWP service"""def__init__(self):
dict.__init__(self)self['cert_id']=settings.MY_CERT_IDdef setNotifyURL(self, notify_url):
self['notify_url']=notify_url
# snip more wrapper functionsdef plaintext(self):
"""The plaintext for the cryptography operation."""
s=''for k inself:
s+=u'%s=%s\n'%(k,self[k])return s.encode('utf-8')__str__=plaintext
def encrypt(self):
"""Return the contents of this order, encrypted to Paypal's
certificate and signed using the private key
configured in the Django settings."""# Instantiate an SMIME object.
s = SMIME.SMIME()# Load signer's key and cert. Sign the buffer.
s.load_key_bio(BIO.openfile(settings.MY_KEYPAIR), BIO.openfile(settings.MY_CERT))
p7 = s.sign(BIO.MemoryBuffer(self.plaintext()), flags=SMIME.PKCS7_BINARY)# Load target cert to encrypt the signed message to.
x509 = X509.load_cert_bio(BIO.openfile(settings.PAYPAL_CERT))
sk = X509.X509_Stack()
sk.push(x509)
s.set_x509_stack(sk)# Set cipher: 3-key triple-DES in CBC mode.
s.set_cipher(SMIME.Cipher('des_ede3_cbc'))# Create a temporary buffer.
tmp = BIO.MemoryBuffer()# Write the signed message into the temporary buffer.
p7.write_der(tmp)# Encrypt the temporary buffer.
p7 = s.encrypt(tmp, flags=SMIME.PKCS7_BINARY)# Output p7 in mail-friendly format.
out = BIO.MemoryBuffer()
p7.write(out)return out.read()
The settings required are as follows:
MY_KEYPAIR='keys/keypair.pem'#path to keypair in PEM format
MY_CERT='keys/merchant.crt'#path to merchant certificate
MY_CERT_ID='ASDF12345'# code which Paypal assign to the certificate when you upload it
PAYPAL_CERT='keys/paypal.crt'#path to Paypal's own certificate