I’ve been studying accessibility. After reading a whole bunch of stuff I decided I should try to make my blog as accessible as reasonably possible. This blog post chronicles some of the changes I’ve made. If this helps you enjoy my blog more, please do let me know. If I made anything worse, please also let me know
Different wordpress theme
This new theme features:
- High-contrast design (good old black-on-white)
- relative font sizes in CSS
- reasonable serif font
- clean “pure” CSS for layout
- layout/ordering of elements of html on the page is reasonable
Different theme configuration
Some of the changes:
- Re-ordered the widgets
- Replaced the calendar widget with a list of archived posts
- Added more descriptive titles to the widgets
- Changed the custom HTML for the RSS link (relative font size, alt tag for icon)
- Stop using drop down menus for lists of links
- Made the blog tagline more descriptive
I also tried replacing the search widget with something more reasonable but failed to hack that up. If someone from wordpress could please make it resemble something like
<form method="get" id="search_form" action="http://lsimons.wordpress.com/">
<div>
<label for="s">Search:</label><br />
<input type="text" name="s" id="s" />
<input type="submit" value="Go" />
</div>
</form>
that would be great. Or, if someone knows how to do an accessible search box on a wordpress.com blog, please let me know
Secondly, it would be nice if the theme could be modified to have “skip to content” and “skip to navigation” links, which I seem to have no way of doing myself.
Change of blog contents
Some of the changes:
- Fixed some bits of broken HTML
- Added reasonable (descriptive but less than 100 characters) alt tags to images
- Replaced use of <h4> with <h3> in blog post contents (so that the header structure goes h1 – h2 – h3 properly)
- Cleaned up the page navigation to have just Home and About pages
- Cleaned up the About page, in particular getting rid of the strike-through links which seems to be a subtlety that is easily lost when using a screen reader
“Doing” accessibility using tools
I got rather depressed a couple of years ago with the complete lack of tool support, and basically just gave up. Recently I talked to some front-end engineers at the BBC (which cares a great deal about accessibility) who gave me some useful pointers. Tool support has now gotten a lot better. You should take a look around!
Here’s three links:
- WebAIM WAVE, an accessibility validator. I feel this validator is much better than any of the others; for example it doesn’t accuse me of using ASCII art when it encounters a block of java code. It also doesn’t sounds like a stern kindergarten teacher or some haughty user experience expert.
- Fangs, an easy-to-use firefox plugin to do “screen reader emulation”. Basically it processes a web page and then spits out text that is roughly what a screen reader would say.
- WebAIM Screen reader simulator, gives you an idea of what a screen reader does, good to try if you’ve never seen an actual screen reader in action.
Dive into accessibility
If you’ve never bothered about accessibility before but you’re interested now, I suggest you start your reading with Dive into Accessibility, a free online book with lots of clear practical advice by someone that knows his stuff and actually builds websites out there in the real world. From the introduction:
Don’t panic if you are not an HTML expert. Don’t panic if the only web site you have is a personal weblog, you picked your template out of a list on your first day of blogging, and you’ve never touched it since. I am not here to tell you that you need to radically redesign your web site from scratch, rip out all your nested tables, and convert to XHTML and CSS. This is about taking what you have and making it better in small but important ways.
IntelliJ IDEA was open sourced yesterday!
Codebase overview
- over 20k java source files, totalling just over 2M lines
- over 150 jar files
- over 500 xml files
- build system based on ant, gant, and a library called jps for running intellij builds for which the source apparently is not available yet (see IDEA-25160)
- Apache license header applied to most of the files, copyrights both jetbrains and a variety of individuals, license data not quite complete, no NOTICE.txt (see IDEA-25161)
- ./platform is the core system
- ./plugins plug into the core platform
- ./java and ./xml are bigger plugin-collection-ish subsystems
Building…
- Install ant (there is an ant in ./lib/ant)
- Run ant
- Build takes about 7 minutes on my macbook
Running…
On Mac OS X I run into 64 bit problems. Falling back to a 32-bit version of JDK 5.0 works for me…seems like jetbrains may have just fixed it.
cd /System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin sudo bash mv java java.orig lipo java -remove x86_64 -output java_x32 ln -s java_32 java cd - export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home export PATH=$JAVA_HOME/bin:$PATH rm -Rf out ant cd out/artifacts unzip ideaIC-90.SNAPSHOT.mac.zip open ./Maia-IC-90.SNAPSHOT.app
Loading the idea source code into your just-built ide works seemlessly (just navigate to your git repo, an intellij project is already set up in the .idea directory.
Reading the code
com.intellij.idea.Main uses Boostrap and MainImpl to invoke IdeaApplication.run(). We’re in IntelliJ OpenAPI land now. Somewhere further down the call stack something creates an ApplicationImpl which uses PicoContainer. w00t! That makes much more sense to me than the heavyweight OSGi/equinox that’s underpinning eclipse. Its where plugins and extensions get loaded, after which things become very fluid and multi-threaded and harder to follow.
So now I’m thinking I should find a way to hook up IntelliJ into a debugger inside another IntelliJ…though it’d be cool if intellij was somehow “self-hosting” in that sense. Here’s hoping the intellij devs will write some how-to-hack docs soon!
See the javadoc.
Example usage:
import java.lang.management.ManagementFactory;
import java.lang.management.OperatingSystemMXBean;
public class LoadAverage {
public static void main(String[] args) {
final OperatingSystemMXBean osStats =
ManagementFactory.getOperatingSystemMXBean();
final double loadAverage = osStats.getSystemLoadAverage();
System.out.println(String.format("load average: %f", loadAverage));
}
}
This is a rather useful feature if you are writing software that should do less when the overall system load is high.
For example, if you’re me, you might be working on a java daemon that is instructing some CouchDB instances on the same box to do database compactions and/or replications, and you could use this to tune down the concurrency or the frequency if the load average is above a threshold.