locked
WAI Accessibility and Javascript (not AJAX-related) RRS feed

  • Question

  • User500537205 posted

    Hi,

    Nice work on releasing Beta3.

    Some of our customers would like their web pages to "work" without the requirement for Javascript (since it is referenced as a WAI "Single A" Conformance requirement). For example, sorting and paging in a GridView require Javascript. (I put the word "work" in quotes because the term is open to interpretation.)

    It may well be out-of-scope but is it an aim to consider producing controls that work with Javascript switched off?

    By the way, this query is unrelated to use of AJAX techniques. I'm referring to things like Sorting and Paging in GridViews.

    Thanks,

    Martin

     

    Tuesday, October 24, 2006 3:25 PM

All replies

  • User-534056067 posted

    Hi Martin,

    Your question is a good one.  You are not alone.  I share this concern.  And I've been contacted (months ago) by another member of the community who expressed similar sentiments.

    It's definitely something I'd like to pursue in the future but I must admit that it isn't actually scheduled work that's "on my plate."

    Generally, the approach I've seen developers use in these cases is to force the page to postback whenever it would otherwise try to use some JavaScript.  That way it can do the work on the server, instead.

    Perhaps you and I could brainstorm here about how the adapters could be modified to handle the NOSCRIPT case better.

    Tuesday, October 24, 2006 7:48 PM
  • User500537205 posted

    Hi Russ,

    I haven't had time to look at this in too much detail. Feel free to point out gaps in the logic.

    From my understanding, taking the GridView Sorting and Paging as an example:

    To implement a NOSCRIPT GridView:

    a) the Render (or earlier) operation for Sorting and Paging UI must replace elements that use JavaScript with those that don't.

    Typically, this means SUBMIT buttons, with values (and/or Ids) that indicate the desired operation.

    This operation could be performed by a Control Adapter.

    b) the PostBack handling would need to be modified, to correctly extract the desired operation from the SUBMIT button's value/Id.

    This operation would probably be performed by a GridView-derived server control.

    As such, it seems that the overall NOSCRIPT behaviour could end up being distributed across (at least) two classes - the Control Adapter and the GridView-derived class. The Render operation could be implemented in the GridView-derived class, for modularity.

    However, there is still the case where a developer wants to have both CSS-Friendliness and NOSCRIPT-friendly behaviour. If the GridView Sorting UI is not based on Anchor+JavaScript, would it break the Gridview Adapter?

    Just a braindump at the moment - no major breakthroughs.

    Thanks,

    Martin

     

     

    Thursday, October 26, 2006 6:19 AM
  • User-1467029032 posted

    It has been a year and a few months since this thread saw activity.  Has there been any movement in this space in the interim; any suggestions on possible workarounds?  To me the use of JavaScript to perform these operations is a bothersome "feature." :)

    Thursday, January 17, 2008 9:28 AM