Re: [Mailman-Developers] Accessible DOM manipulations
--On 6 July 2006 16:45:26 -0400 emf [EMAIL PROTECTED] wrote: Can you help me understand the basis for this claim? I have looked into the matter somewhat deeply and this works in every browser I have come across that supports JavaScript: And the ones that don't? -- Ian Eiloart IT Services, University of Sussex ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
Ethan wrote: One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a overview page variant and then being able to expand as necessary. I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of hidden text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, Brad Knowles [EMAIL PROTECTED] wrote: Ethan wrote: One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a overview page variant and then being able to expand as necessary. I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of hidden text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see. I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting What a great ride! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
Ethan wrote: One example is keeping extraneous text hidden until it is selected; I imagine that someone using a screen reader/portable device would appreciate being able to read a overview page variant and then being able to expand as necessary. An overview at the top of a page is good usability. This is referred to as inverted pyramid [1]. The inverted pyramid is a type of writing style where conclusions are presented first not last. It begins with a conclusion then moves to the key information followed by background information. Usability studies show that web users want instant gratification. That is why the inverted pyramid style is important. Brad Knowles wrote: I would much prefer to do this without JavaScript. Because you can't guarantee that you know the way that page would be rendered if you send all sorts of hidden text that isn't shown until such time as someone does something to make it appear, and you can't control what kinds of mailicious cross-scripting attacks people may throw at you, it's best to simply not send anything that the user cannot currently see. Bryan Carbonnell wrote: I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. Default set to off? For the non JS option maybe provide a table of contents or overview at the top of the page with plain old anchors to jump down to detailed information. Personally, I usually also dislike expandable/collapsible content is that relies on user action. But I haven't used Ethan's version yet. Hope it is keyboard friendly. BTW, some degree of accessibility checking for the app can be done simply by using keyboard techniques like tabbing (using no mouse). Blind users often browse web sites by tabbing from heading to heading or link to link. Keyboard techniques, such as tabbing through a page (tabbing through a page usually goes in the same order as a voice browser would read), is a good quick test. By tabbing you can check for any elements that cannot be accessed with the keyboard or that are in an illogical tabbing order. The first exercise I have my Web Accessibility class do is disable their browser. The the idea is to give them an idea as to what it's like to have access to the web restricted. It's goal is to help them to understand what it feels like, and hopefully get them thinking about how these problems can be overcome. These are their instructions: begin exercise No, don't unplug the phone cord or Ethernet connection! Instead we are going to selectively disable certain features in your web browser. 1. Go into your preferences in your browser and turn off any and all of the following, if you can. (You may have to poke around a bit in preferences or internet settings, and not all browsers will allow you to disable everything. But the general intent is to turn off as much as you can.) - Images - Sound - Java - JavaScript - Style Sheets 2. Take your mouse/track ball/pointing device, unplug it, and throw it out the window. Okay, don't really do that, you might not be able to find it again. But don't use the mouse for the purpose of this exercise. 3. Look up the keyboard shortcuts for your browser in the help files or manual pages. Oops, I should have told you to do that before removing the mouse. Well, just remember that people with disabilities aren't magically born knowing how to run computers either, and if the help system is not accessible, they are in as much trouble as you are now! 4. With your disabled browsing system, look at five different web sites and attempt to use them. These should meet the following criteria: - They are sites you've used before. - They are sites where you can actually do something, and that something is of interest to you personally. - They are different types of sites (not all news, not all e-commerce, not all personal pages, etc). Look at a variety of sites. - Try to use these sites as you normally would, and record where you encountered any difficulties. What Was Your Experience Like? 1. What sites did you visit? 2. Were you able to perform your normal tasks? 3. What kind of obstacles, if any, did you encounter in accessing those sites? /end exercise Best Regards, Laura [1] http://www.d.umn.edu/goto/usability#pyramid ___ Laura L. Carlson Information Technology Systems and Services University of Minnesota Duluth Duluth, MN U.S.A. 55812-3009 http://www.d.umn.edu/goto/webdesign/ ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy:
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, Laura Carlson [EMAIL PROTECTED] wrote: An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. Default set to off? That'd be my preference. -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting What a great ride! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
Brad Knowles wrote:
I would much prefer to do this without JavaScript. Because you can't
guarantee that you know the way that page would be rendered
Can you help me understand the basis for this claim? I have looked into
the matter somewhat deeply and this works in every browser I have come
across that supports JavaScript:
document.getElementById('foo').style.display = 'none';
An intelligent layout allows you to minimize the amount of page
rejiggering that goes on when you display text.
Visual tests using Greasemonkey allow you to see all the visual states a
page can get in (including different sized displays) to ensure you don't
get into an unpleasant corner.
Perhaps you mean to say that the variety of CSS implementations prevents
me from knowing how a UA will render the page. Strictly speaking, this
is true; pragmatically speaking, there exists suitable CSS that works in
all current browsers that I know of.
if you send
all sorts of hidden text that isn't shown until such time as someone
does something to make it appear,
The document with all the hidden text shown will be something like a
full detail view; after all, I've promised the page will work fine
with JavaScript off.
and you can't control what kinds of
mailicious cross-scripting attacks people may throw at you,
I am unaware of any cross site scripting (XSS) attacks that can occur
when a linked-in stylesheet uses the event model to alter the style of a
element.
Perhaps you are referring to the approach of using some mechanism
(XMLHttpRequest or naive furl() type stuff) to fetch new bits to go into
a page. This definitely a risk, and one I'm disinterested in playing with.
I intend to use XMLHttpRequest to fetch JSON messages like preferences
saved from the server. These messages will be carefully scrubbed and
come only from server-generated translations, rendering them an
improbable source of XSS.
I also intend to use it for one-way communication where the client
informs the server that something has changed via JSON. As with all form
submissions, each JSON submission will have to come with the appropriate
hashcash-esque validation element to be considered to come from the user.
The UI benefit that drives the above choice is that I can provide the
user with the UI state of the web app at the last time they used it, no
matter what machine they come from.
it's best to simply not send anything that the user cannot currently see.
I'm not sure I understand this principle.
Most people have internet bandwidth that is inferior to the rendering
speed of their browser, and a monitor that is smaller than most page
content; some people (like those using screen readers) have essentially
a 2d/linear monitor.
This suggests that sending fewer, larger chunks is preferable to
sending many smaller chunks when the user will be aware of the load
time. The way modern rendering engines work makes 'hidden' text *much*
faster to load during initial page rendering than it would if it were
all displayed.
One use case is where the new user clicks on all the help buttons to
learn what's going on; a delay rendering help increases exploration cost.
Another one is the way people read on the web. Nielsen [1] and many
others in the usability field have shown that people scan, looking for
key words, rather than reading. The fewer words the shorter the seek
time and the more likely the user will do an exhaustive search of the
page for what they're looking for.
[1] http://www.useit.com/alertbox/9710a.html
When it comes to screen readers, text *is* space; sighted individuals
can skip big swaths of text with a single saccade, but a blind user must
give voice to enough of the text to hear where they're going.
This makes scanning text both temporally and cognitively more expensive
than it is for sighted users.
As screen readers *do* respect hidden/shown elements, I can
significantly improve the user experience for them, while making life
easier for visual uses as well.
On somewhat of a side note, I have heard a certain amount of antipathy
towards JavaScript in this forum. I know it was unpleasant in the late
'90s, but it is much better and more cross-browser these days.
I'm fairly certain that *some* author-initiated manipulation of a user's
experience of a node set is obligatory in any conceivable Web; the only
alternative I can see to using JavaScript or another interpreted
language would be using something like XSLT, a horror that I shrink from
even contemplating.
~ethan fremen
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
Re: [Mailman-Developers] Accessible DOM manipulations
Bryan Carbonnell wrote: I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. I'm a little reluctant to add another bit flip to mm_cfg when you'll be able to delete the .js files or forbid access to the js directory in apache and get what you want. Or you could avoid subjecting all your users to your preference and use the no-JS variant that will always be available, or just turn JS off in your browser. Can you help me understand your opposition to Javascript in a webpage you serve? Something specific rather than in principle, if you would be so kind; I often have a hard time applying abstract concepts to code I'm in the process of writing. Thanks for your help, ~ethan fremen ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
On 7/6/06, emf [EMAIL PROTECTED] wrote: Bryan Carbonnell wrote: I have to agree with Brad on this. An option may be to give the site admin the ability to turn the JS on/off site wide with a mm_cfg.py variable. I'm a little reluctant to add another bit flip to mm_cfg when you'll be able to delete the .js files or forbid access to the js directory in apache and get what you want. Or you could avoid subjecting all your users to your preference and use the no-JS variant that will always be available, or just turn JS off in your browser. Can you help me understand your opposition to Javascript in a webpage you serve? Something specific rather than in principle, if you would be so kind; I often have a hard time applying abstract concepts to code I'm in the process of writing. Ethan, For me it's nothing specific. It's more philosophical. I am a very minimalist when it comes to the 'net. Plain text e-mail and no scripting or embeded audio/video on web pages. I think the content of the page should stand on its own legs and not rely on fancy tricks to make it appealing. I've seen WAY to much bad scripting (and I'm not implying that the code you are going to write is going to be bad) to actually want to implement and Javascript. I also know that quite a few of my users are going to be up in arms if scripting gets added to the pages. I just want to have the option to NOT use in in MM. I realize that I can just delete the JS file or disallow it with Apache, but I feel that since this is a MM endeavour I should be able to control it within MM and not have to resort to things like you mention to disable the JS. I know this sounds negative, it's not. I'm really glad the UI is getting overhauled. I have done what I could with the XHTML/CSS patch that I wrote, but I know the UI could be a LOT better. Just my $0.02 -- Bryan Carbonnell - [EMAIL PROTECTED] Life's journey is not to arrive at the grave safely in a well preserved body, but rather to skid in sideways, totally worn out, shouting What a great ride! ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
Re: [Mailman-Developers] Accessible DOM manipulations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 6, 2006, at 4:45 PM, emf wrote: On somewhat of a side note, I have heard a certain amount of antipathy towards JavaScript in this forum. I know it was unpleasant in the late '90s, but it is much better and more cross-browser these days. I'm sure a lot of that comes from me, inspired by early experience and my own general paranoid dinosaurism. OTOH, I remember Guido telling me a few years ago that I might as well give up on that one, and so I have -- mostly. That's why I love NoScript so much :). I'm no web developer expert by a long shot, but I've been following the discussions and istm that Ethan is striking a reasonable balance and is being extremely diligent in his research. I for one am quite eager to see what he comes up with! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRK2w3HEjvBPtnXfVAQKNWgP+Okh3nAD4DmkvIA8FyvVw5z301gyEIiKS pzR2qKN3Rgl6uppBV0cvT09VQf9tVEFqnGOF2kw116tZ7CS8QjccAbend5mY0rlh grXIVahKR0EuLvjODronVPJ4fSPCd4oul5alZklXxmOJXyDTEtCmhUdwaeHsvM7P 1359VTu+YGA= =mjCZ -END PGP SIGNATURE- ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=showfile=faq01.027.htp
