Comments on: An attempt for a more accessible edit-in-place solution

By: Jeff Brown

Jeff Brown — Fri, 11 Jan 2008 16:33:40 +0000

cool I'm thinking of making a field that pops up a drop down instead of a text widget to limit the options, something like;

[div]foo[/div]
[select]
[option]foo[/option]
[option]bar[/option]
[option]baz[/option]
[option]quarfle[/option]
[/select]

That would really work for me!

By: Andreas

Andreas — Wed, 09 Jan 2008 11:58:47 +0000

Cool! I've used the form-inside-semantic-elements approach myself for editing articles on my blog, but as editing requires login not everybody will suffer.

I understand that "screen readers work in different modes and nobody expects an input box in a heading", but what are the actual drawbacks of putting an input in a heading if we leave out SEO?

By: Chris

Chris — Sun, 06 Jan 2008 11:39:00 +0000

@Isaac No I cannot, for the main reason I said in the post: it is just not accessible as screen readers work in different modes and nobody expects an input box in a heading. I added these as people would come up with CSS only solutions to counteract my evil JavaScript ways - as CSS is sooo much easier and doesn't need hacks, ever*

Assistive technology understands changes in the Dom - if you notify them, but they don't get hover changes in CSS. When you talk accessibility you have to start with a logical HTML construct, and then you can work out how to style it. The example I've given does have issues, which were mentioned.

I've sent the prototype to some friends of mine who use assistive technology and we can see what is going on.

As to XHR firing onchange - it now fires onblur, which is factually the same :)

* may contain irony

By: Isaac Z. Schlueter

Isaac Z. Schlueter — Fri, 04 Jan 2008 20:02:06 +0000

Can't you do it even more unobtrusively by building it to work entirely with CSS, and just ajaxing the form submission? Seems like an awful lot of script to do the hiding and showing of form elements when a :focus selector could do the heavy lifting. (Of course, IE might choke on that, I forget. If so, just add and remove a "focus" class, and rely on .focus instead of :focus. IE would then require JS to work, but oh well. Maybe a CSS hack could be employed to make non-JS IE just always show the inputs or something.)

Here's a first crack at it (tested only in Safari and Firefox so far.)
http://foohack.com/tests/editable.php

Also, the XHR could fire off on the onchange event instead of waiting for form submission, which would probably "feel faster" to the user, and be less actions. (Of course, it'd also be less forgiving of unintended changes.)

By: James Broad

James Broad — Fri, 04 Jan 2008 09:17:26 +0000

Great stuff Chris! Very slick and i think you would get some happy screen readers/non JS adopters.

I think to take this idea and make it much more sophsticated, it would be cool to play with being able to specify that certain elements on a page were editable (h1, li, a etc.). Almost venturing down a WYSIWYG route, just limiting to the content, though?

Technical problems may hamper this idea, how would you be able to uniquely identify the information etc? You would have to rely on server side pre-processing to scan over the content, work out the elements to make editable and have a sensible way of writing out a respective form input field hook?

note Christian: broken link "solution described here"...