Our Technology Stack

We’re building our new website in Drupal, which in turn is built in PHP. Our development machines run a mixture of Fedora and Ubuntu Linux, and we keep a collection of Macs and PCs around for testing purposes. All of our code lives in a Git repository (Check out our post on it!). We’re currently using Omega as the base theme for our heavily customized templates.

Although internally we track code and manage deployments with GitLab, we’re gradually posting some publicly released code on Github. Have a look!

We also maintain a static asset server, which caches unchanging resources for us to speed up requests across all our other websites, at static.lanecc.net. It uses Nginx to run a private website, not exposed to the outside world. Requests over HTTP are made directly to Varnish, a fast reverse caching server, who makes them (and aggressively caches them in RAM) for you. Requests over HTTPS are made first to Pound, an HTTPS terminator, who then asks Varnish for them.

2 thoughts on “Our Technology Stack

  1. I’m interested to know your perspective on the following issue: are there any language-related barriers to accessibility that WCAG didn’t address? In other words, do you think that from one language to another, there are some unique guidelines that should apply?
    Thank you,

    • That’s a fascinating question. WCAG 2.0 certainly provides some improvements for supporting multiple languages, like 3.1.1, where you’re supposed to provide a way to determine the language of a page, or 3.1.2, which allows for specifying the language of a section of a page.

      But I wondered about text direction and character encoding. Enforcing text direction isn’t an obvious requirement, but you could make an argument that 1.3.2, Meaningful Sequence includes that requirement. Character encoding (and with it support for the non-ASCII characters many languages use) isn’t an explicit requirement of WCAG 2.0. It comes closest under 4.1.1, but I don’t think it’s a requirement. I can see there being an issue with a page that doesn’t specify a character encoding and a screen reader misunderstanding some unicode.

      Afraid otherwise I’m not much of an expert at languages, and wouldn’t know enough about their differences to be able to point out any shortcomings of WCAG 2.0 when it comes to addressing languages.

Leave a Reply

Your email address will not be published. Required fields are marked *