Previous Entry Share Next Entry
Long-term question: will Querki's lo-fi interface also be the accessible one?
jducoeur wrote in querki_project
One of the issues I've been gradually growing acutely conscious of with Querki is accessibility, and specifically the tension between "snazzy UI that works well for the sighted" and "accessible". (One of these came up yesterday -- in order to make one of my features work properly in CSS, I *suspect* I wound up breaking accessibility for that feature. The truth is, I don't understand that area anywhere near well enough yet.)

For the short term, I'm making the conscious decision that I'm going to focus on making the UI as sexy and efficient as I can for the likely early-adopter crowd. Frankly, given that *I* am going to be the most hardcore early adopter, that decision is partly for my own sanity -- my patience with tech-imposed user inefficiency is going to be low. That means that accessibility takes a back seat in the short term -- and IE 6 is deliberately shoved into "non-consideration". But I'm well aware of the fact that this can't be a long-term position: besides the hard business fact that it cuts off a significant chunk of the eventual target audience, the sheer morality of the matter rather bugs me. (This post was in part occasioned by metahacker's comment in this fine discussion, observing that ignoring IE6 is discriminatory in some fairly serious ways.)

So while I'm not going to actually build the accessible (in various senses) UI(s) yet, I *am* about to start rejiggering the architecture so that we can do it right in a little while, once the overall shape of the project has stabilized. The core notion is that the "website" UI -- all of the HTML layer, and even the notion that we're connecting via HTTP -- is going to get shoved into a module. The bulk of Querki will operate behind an API. The bulk of the system will be focused on collecting data and "rendering" it into wikitext; how that wikitext gets turned into an actual UI will be up to the renderer that the user is hooked up to.

Frankly, that's probably the healthiest architecture anyway, so I'm pretty comfortable with that decision. It's not perfect, and will requires some nuancing as things go -- for instance, a Space being used for mobile may not even be *shaped* quite the same way as one being used entirely for desktop, and it wouldn't astonish me to find that there are some similar nuances for accessiblity -- but it seems like the right direction.

I'm focused on the "fancy UI" for now, but the other ones are percolating in the back of my mind. And a question just occurred to me. One of the "UIs" I need to build is the one focused on "lo-fi" browsers -- pre-10 IE, in particular. Another is the one focused on accessibility. Are they the same? I don't think it's obvious that they are, but when I think through the way both are likely going to have to be built, it seems like many of the same decisions in both cases. They should both be reliant mainly on older versions of HTML. They should both reduce or entirely eschew Javascript dependency, and shouldn't depend on CSS tricks for usability. They both need to be more rigorously focused on *content*, with less emphasis on being *pretty*. In both cases, it is probably necessary to sacrifice a bit of UX efficiency, but they must be entirely *functional* for all significant tasks.

For the moment, this is a fairly abstract question: it's certainly going to be a minimum of six months before I can even begin to think about any of this. (The first "alternate UI" will probably be the first draft of the mobile interface.) But sometime in the next year, before everything begins to set in stone, I'd like there to be an effort to start addressing both older browsers and accessibility in a rigorous way.

When that time comes, I may well wind up looking for help building it, especially if Querki is still a one-man show at that point. (If we wind up with a million users, I can hire people to deal with this, but I can't assume that level of success.) But in the shorter run, I'm interested in folks' thoughts about it. Many of you are more experienced than I at both UX and accessibility issues, so I'm curious whether you agree with my intuition that it would be appropriate to tackle these two problems as one "support all browsers" project...

  • 1
(Deleted comment)
This assumes that IE-anything is the browser for accessibility. May I ask why you make that assumption?

Actually, I don't -- I'm just using IE6 as an example because of its ubiquity. It's more a matter of "supports older browsers", that don't have all the fancy HTML5 bells and whistles. As far as I know, IE6 comprises the largest (and probably most difficult) single chunk of that space.

The reason for the association between "supports older browsers" and "accessible" is mostly because, as far as I can tell, it's the shiny new features that tend to *break* accessibility. It appears (and again, I could be wrong) that sites which are built around older specs tend to be more compatible with screenreaders and the like; the difficult problems tend to come when you are adding in fancy AJAX/COMET/etc features.

This feeling is partly driven by the recent complaints about LJ, and the way that its fancy new AJAX interface seems to have caused lots of accessibility headaches. My suspicion is that Querki's fancy UI will have *some* similar problems -- probably not completely broken, but it's increasingly looking to me like some things won't work right.

In other words, it isn't so much that new browsers can't be accessible -- it's that, the more you use fancy new features, the easier it is to find yourself *not* accessible, and the trickier it is to be rigorously accessible.

So I'm trying to suss out the principles and priorities that will lead to a highly-accessible UI. And so far, they seem similar to those for supporting older browsers well. But that's just a guess, and I could be off-base...

(Deleted comment)
Even Adobe has bent its proud and hated neck on some points, though Flash shall, I fear, ever be closed to Blind people.

Interesting. I'm fairly sure that it is *possible* to make Flash accessible -- I just spent three years mainly doing Flash programming, and the hooks all seemed to be there. But the system was overly complex, so it wouldn't surprise me if nobody ever uses it.

But anyway:

Things are now changing so quickly in terms of what is and is not accessible that I think your best bet is to just bring some people like my wife on-board, ask them to test with a platform-agnostic browser like Chrome, and tell you what works and what doesn't.

True, and we'll see. It may well be that I'm over-thinking this. Querki is *probably* going to be better than the average website right out of the box, simply because it is so content-centric and less full of random cruft all over the place. I'm fairly sure some things will be broken, but it might not be terrible to begin with.

I'm just under-confident about what it will take to get from "passable" to "good", and I would *like* to eventually have it be genuinely good from an accessibility perspective...

(Deleted comment)
Interesting. I confess, I didn't try -- the Flash app I was working on was *very* fundamentally graphical, so there was no point.

(It was a fraud-detection app, and users were expected to be doing handwriting comparison, examining graphs, and so on. Indeed, we wound up getting several patents on the various graphs and charts in it. I don't have any clue how a blind person could even *do* that specific job, since the techniques used are so visual.)

This is mostly speculation on my part, though -- I didn't even play with those interfaces. It *appeared* that Flash had hooks for the operating system's assistive layer, but for all I know they may be non-functional.

Actually, no -- here's the overview. The tech is definitely there, but the app has to *specifically* turn it on and hook into it, and preferably use the components that are designed for accessibility. (Which many are not.)

I suspect that nobody makes any attempt to use that, simply because if you're bothering to use Flash, you're probably very graphically-focused to begin with. This was actually a huge argument within the company: the main reason why I kept putting my foot down that we needed Flash was specifically because the UI was so intensely visual. If you're not all about the visual bells and whistles, then using Flash is generally more trouble than it's worth...

"Amazon even made the Kindle App for the iPad accessible within the last month or so, and my wife has been going to town with it."

Do you happen to know if that accessibility also works on an iPod Touch? kestrell might be interested in that...

Oh, yes! The Kindle app works on all iPads, iPad Minis, iPod 4Th gen and 5, and iPhones.. I get free books almost every day, and I even managed to buy a few. Love that app. Braille support needs improving, but as has been pointed out elsewhere, it's the fault of the operating system *not* Amazon.

Most people I know use IE 8 or 9 or maybe even 10, if they are not using FireFox or Google Chrome on Windows. I don't think JAWS or NVDA supports IE6 now. On the Mac, we're using the latest version of Safari, or Google Chrome, or Firefox. And on iDevices, we use Safari. or Google Chrome, or there are a couple of other browsers out there.

In most cases, though, whatever browser we use, we tend to like using the mobile versions of sites, because the interface is less cluttered. You get the essentials and can do what you need to do (with a couple of exceptions like Amazon and Audible).

Ah -- interesting. Hadn't occurred to me that this would be a side-benefit of mobile sites. Querki is, by and large, going to try to avoid clutter, so it may be less of an issue; we'll see.

(Of course, even Google has begun to get more cluttered with time, so who knows how far my good intentions will get me...)

Agreed. I do not like Google sites, but I work with the sites in their cluttered state, because the "screen-reader friendly version" lacks features. Same with the Amazon and Audible sites and their "accessible" versions. They are more stripped down than the mobile sites, I think.

Yeah, and that's going to be the trick. I suspect that I'm going to eventually need an "accessible" version; right now, I'm trying to design the architecture so that that isn't likely to be missing anything important when it happens...

Random thoughts in no particular order

1. Newer standards are doing better at noticing accessibility. Maybe not addressing, but at least thinking about it. I just went to a UX talk on WAI-ARIA, which helps you mark up your HTML with indicators. It looked like half of a good idea; the resulting website sounded horrid to me, but the designer was very proud of it, and was testing it with screen reader users, so perhaps it's useful in a way I'm not grokking. Or perhaps the bar is set very low, given how hostile most sites are.

2. Innovation in screen readers is very, very slow. :-/ This may affect your "two year plan" or whatever.

3. Designing for accessibility is a little bit like LukeW's mantra, "mobile first"--it forces you to think about what is *really* important, and presenting that in a clear fashion. I would encourage you to think about mobile first.

4. Pretty is a feature, the same way that performance is a feature, and reliability, and compatibility, ... You can choose not to have this feature, but users will definitely notice, and it may hurt adoption. However, pretty can be achieved in a variety of ways, and many of them will work just fine for lowviz people or people on browsers that don't support gradient backgrounds or image borders or other cool new HTML/CSS hotness. :) You may also be surprised at how much CSS / JS you *can* use.

5. If it isn't functional then it isn't good UX. Function comes first; form follows; style shouldn't interfere with either. (Useful, usable, beautiful; each requires the prior, or people leave it on their mantlepiece.)

6. It's not too early to start designing what you want it to look like. In fact, it's the perfect time. Pushing a design through from back all the way to the front can help you focus your feature set, and uncover architectural requirements you didn't know you had. I can definitely share thoughts on this process if you want...

7. At the other end of the spectrum, yeah, if you design Querki to be something like a RESTful API, then it's easi*er* to swap out front-ends--but you'll still need to understand things you want users to do with it, how, in what context, from what devices, etc. What's the single most useful, most obvious use case you can think of?

Re: Random thoughts in no particular order

... that's a good bunch of points, and I suspect it's going to take half a dozen comments to respond properly. Most of that will have to wait until tomorrow, but let's start tonight with the last, and in some ways most interesting bit:

What's the single most useful, most obvious use case you can think of?

So the tricky bit about Querki is that, since it's a platform rather than an application, the term "use case" is fuzzy. Indeed, I'm tending to misuse it -- most of the "use cases" that I refer to are actually applications, each of which will have a set of use cases unto itself.

That said: the honest-to-god truth is that I'm not sure. I have a solution that I know I like, and I know that *I* am going to use in at least a dozen different ways pretty quickly, but I can't pretend that I have any real confidence about which apps are likely to resonate with other people.

This is actually driving much of my approach: I'm doing the crossing-the-chasm exercise by throwing a *zillion* apps at the wall, letting them evolve, and seeing which ones stick. The core goal of Querki is to make it stupid-easy to build easy little apps, and there's no better way to demonstrate that than by doing it myself.

It occurred to me, as I was thinking about this, that it's worth stating the *engineer's*-view mission statement of Querki. I tend to speak in marketing terms when I talk vision, because I'm trying out elevator pitches, but the techie view of the system is this:

Querki is a platform for building easy, small, collaborative data-management applications.
As with any good vision statement, every word there is critical. That data-centricity is essential to the concept: we're trying to make a system that lets you create, edit and view semi-structured data, using it in ways that make sense for the application at hand. And ultimately, that's driving a lot of decisions...

Re: Random thoughts in no particular order

As for this point, which is awfully important:

I would encourage you to think about mobile first.

I somewhat agree, and I *have* thought about mobile quite a lot -- which is part of why I'm not seriously designing for mobile yet.

The thing is, as I've worked through the scenarios for the apps, I've tended to conclude that, for apps that are are mobile-heavy, the mobile side often wants to be wildly *different* from the desktop side.

The best example here is probably the Carolingian Site Database. There are many use cases and scenarios that I've played with, and the most interesting conclusion I came to is that I want it to work very differently on desktop and mobile, because I am trying to do different things with them.

The mobile version of the Site DB needs, first of all, to be a native app. It can't be a website. That's because so many of the things I want to do involve using the mobile device *as* a mobile device, for what it's good at. I want to be able to snap a picture of the exterior of a site, as a note to investigate it further. I want to be able to attach the geolocation. When I'm visiting a site, I want to invoke my GPS software directly from the app, to take me there. When I visit inside, I want to be able to take concise notes, take more pictures, and stuff like that.

OTOH, when I'm at the desktop, it's largely about refining that data, and moreover *mining* that data. It's about doing parameterized searches within the database for sites that have the characteristics I need. It's about showing the contact information so I can call them, and recording notes from those conversations. It's about filing reports about events that have occurred there. It's about having conversations with other people who have used this site.

Add to that the fact that, whereas the desktop version will be entirely web-based and always-connected, the mobile version *can't* be. Kate has pointed out to me that even some of the elementary apps, like a shopping list, need to cope gracefully with poor connectivity. The Site DB needs to be able to add photographs and notes even if I have no signal inside.

Thinking this through has largely convinced me that the key is going to be putting the right power in the user's hands to make the app *different* in the mobile environment. The architecture is going to be very different, and is likely to be focused around native Android and iOS apps. (And yes, I fully expect to wind up arguing with Apple about this.)

For now, I'm focusing on some initial apps that are desktop-centric, or where I at least don't see anything terribly *different* about the mobile use cases, to keep the problem manageable. But I'm very conscious that, for some of the envisioned apps, the mobile UI wants to be *wildly* different from the desktop one, and we're going to need to support that...

Re: Random thoughts in no particular order

Continuing on...

Innovation in screen readers is very, very slow. :-/ This may affect your "two year plan" or whatever.

Actually, it's the other way around. I'm assuming that screen readers are *not* going to evolve in any useful ways, and that Querki is going to have to essentially back-port to play well with them. We'll see how much that is actually true.

Newer standards are doing better at noticing accessibility. Maybe not addressing, but at least thinking about it. I just went to a UX talk on WAI-ARIA, which helps you mark up your HTML with indicators. It looked like half of a good idea; the resulting website sounded horrid to me, but the designer was very proud of it, and was testing it with screen reader users, so perhaps it's useful in a way I'm not grokking. Or perhaps the bar is set very low, given how hostile most sites are.

Yeah, we'll see. As I've mentioned elsethread, the truth is that Querki is *likely* to be considerably better than most sites to begin with, simply because my style has always been to be extremely information-centric. I'm trying to avoid having excessive visual clutter on-screen, because IMO that tends to make sites less useful. So in that respect, the site's likely to do decently well.

My biggest concern is really with things like controls and interactivity. I'm likely to get a bit fancy there, because I am intensely concerned about user efficiency -- after all, I'm going to be one of the heaviest users, and I don't like wasting my time. Accessibility isn't going to be a primary concern during my initial build of that stuff, but I'm trying to keep that in mind as design debt, to be addressed later.

So this:

If it isn't functional then it isn't good UX. Function comes first; form follows; style shouldn't interfere with either.

is pretty much gospel in my book, and really isn't the issue -- at least, in ordinary use. But there are places where the lines get fuzzy.

Take for example the motivating case that brought this up. The Wedding App needs Yes/Maybe/No radio buttons for various things like RSVPs. To make those decently pretty, I'm using the jQuery UI version, which are fairly nice -- but they achieve their prettiness by doing Weird Things under the hood. In order to work around a bug in those Weird Things, I had to make a tiny tweak to the CSS on Tuesday, which makes it work Just Right -- but I have a nasty suspicion that, in doing so, it breaks the accessibility.

(Basically, jQuery UI is warping the radio buttons until they really aren't anything of the sort any more, and is maintaining visual shims on-screen to keep them accessible. Those shims were breaking my layout. Hiding them was a trivial one-liner in CSS, but I would guess that it makes those input controls non-accessible as a result.)

This drove home the point that, while I'm focused laser-like on producing good UX on the site, that's good UX for *me*. It's obviously going to need lots of testing with lots of people who aren't me, of course, to find out where my assumptions are wrong. But it's also driven home that there are tensions here that may not be trivially resolvable.

So I'm making a fundamental assumption that we *will* need some variant UIs. Instead of trying to build a single UI that is going to try to be great at the conventional desktop experience *and* accessibility *and* mobile *and* older browsers, I'm architecting on the assumption that that won't work -- that these will have sufficiently different concerns to require at least modest tweaks and changes...

Re: Random thoughts in no particular order

It's not too early to start designing what you want it to look like. In fact, it's the perfect time. Pushing a design through from back all the way to the front can help you focus your feature set, and uncover architectural requirements you didn't know you had. I can definitely share thoughts on this process if you want...

I'm interested, yes.

Mind, I'm a great believer in the slice-of-cake approach to systems engineering, and I'm following it pretty rigorously. I'm identifying a few problems at a time, fleshing them out all the way through, and then proceeding to the next. And I'm building a fairly intricate map of projected use cases, features and architectural designs.

So I'm already doing a good deal of front-to-back design -- indeed, I'm tending to start with the projected look and feel, and then figuring out how to build it. (A hard rule of this project is that *nothing* gets built without a motivating use case. I can't afford to waste the time.)

That said, though, I'm neither a UI nor UX specialist. My strength in running this project is that I am a truly excellent generalist -- I'm reasonably good at many different things. But the flip side of that is keeping a bit of honest humility that I am not *great* at most of them. So your thoughts would be greatly welcomed...

(Deleted comment)
Oh, sure. And I should be clear here: Querki is probably going to be considerably more information-centric than most sites. I mean, the prototype (ProWiki) is utterly spartan, a pure data-management tool.

My concern here is mainly focused on interactive tools, and maybe CSS trickery. I'm starting to realize that some of the things I would like to do with AJAX and CSS *may* be unfriendly to assistive technologies. So I'm starting to think about how to ameliorate that in the medium term...

I have heard some people claim to still be using Lynx as a browser. If Querki runs on *that*, it's probably accessible :-)

Yes, even I know of a few die-hards that use Lynx. Gosh, that brings back memories. I wouldn't even try to use that today!

Last job I was at, we ended up doing work for at least one government agency, which meant making our website comply with a variety of accessibility guidelines.

We anticipated it being an immense pain in the butt. And it was a lot of work, but the hardest part? Was actually diving into the guidelines and really understanding what we could and couldn't do. A whole lot of things we'd assumed would be problematic turned out not to be, and one or two things we thought would be AOK needed work.

The actual implementation was certainly time-consuming, but more because of sloggery - adding alt tags to everything, defining alternate templates for certain types of UI features, restructuring HTML generated from several hundred template files - than the need for lots of clever coding.

I'm not actually too surprised, and it's possible that I'm just wildly over-thinking the problem. Much of the issue here is that I just don't have *time* to address accessibility properly at the moment -- really, I don't even have enough time to understand the problem properly.

So I'm considering that to be Design Debt, on the back burner but important to address before *too* terribly long.

(Hmm. The Project Management Space should probably have a formal category for Design Debt...)

My 2c in the jar -- I think you may be looking at this from the wrong standpoint.

The issue isn't separate tasks 'Make sexy UI' and 'Make accessible UI'. It is a single problem 'Make a sexy UI that is accessible.' (I'm not convinced you can combine 'brain-dead/ie-6' into this mass, but it might be possible.)

Universal design is about starting from barrier free concepts. Accessibility shouldn't be a 'nice to have,' afterthought, or retrofit but the base assumption. Adding inaccessible features should be rare, and only if there isn't an accessible way to do things.

IMO, the second that you start thinking the issues as divergent is the point that you've gone off track.

There has already been a lot of work in the designspace. What are you trying to do that you think is inaccessible?

As mentioned elsethread, it seems to be in the details, particularly with the interaction. (Writing accessible *display* is easy; writing accessible *interaction* I am much less confident about.) The new LJ comment system is an example: by making it more immediate and interactive, they *horribly* broke accessibility, as I understand it. And that's not a matter of simple carelessness -- from what I see of the technology, it is *hard* to make interactive AJAX/Comet-based interfaces that work really well with assistive tech.

I may be off-base here -- it's not a subject I'm well-versed in. But I think there is valid concern here -- it looks like some features to improve general user workflow may be problematic from an accessibility standpoint. My strong suspicion is that producing a really *great* accessible interface is going to require a significant amount of work that is *different* from that for the conventional one...

  • 1

Log in

No account? Create an account