Mailman 3 August 2006 - Mailman-Developers

Re: [Mailman-Developers] The Philosophy of Web Use.
by Laura Carlson 03 Aug '06

03 Aug '06

On Jul 7, 2006, at 12:08 AM, Brad Knowles wrote: >> I'm much more >> bugged by the Flash-only sites that are an avoidable annoyance for >> me, but I can imagine are a scream-out-loud frustration for screen >> reader based users. On August 2, 2006, at 12:08 AM, David Andrews wrote: > As a screen reader person I will say that Flash-only can be made to > work, there is accessible flash, but it is rarely done. If it isn't > implemented, a site can be useless, however you can do a good job, my > department did a whole web training thing in accessible flash, and it > works fine for blind users -- which is good Yes, it's possible to build accessible Flash [1]. In theory, a Flash site should be as accessible as an HTML site; if it provides all the accessibility features that HTML provides, such as alt attributes, keyboard access, synchronized captions for any audio that conveys content, allowing the content to scale to a larger sizes, valid code, links, separating presentation from content, etc. Some flash content even has the potential to aid people with learning or cognitive disabilities. And yes, the more modern versions of screen readers can render it. However, those screen readers can be very expensive, and many users' financial situations preclude even upgrading. There are still a great many people using legacy screen readers out there. In time most people who use screen readers will have software that plays nice with Flash. Until then, though, my advise continues to be to avoid Flash or, if it must be used, to make sure a user has a chance to opt out of it for an accessible page before the Flash begins. Currently the only way to be 100% forward and backward compatible is to create an accessible HTML version of a Flash site. Or only use it for nonessential parts of a web site. Also Flash makes it harder for a site to rank well on the search engines. As far as I know, there are no search engine bots/spiders which can read the contents of Flash. So if you are concerned with SEO you need to include alternative content (ie. text, html) for any Flash content.[2] Best Regards, Laura [1] http://webaim.org/techniques/flash/ [2] http://www.alistapart.com/articles/flashmxmoving/ ___________________________________________ 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/

1 0

Re: [Mailman-Developers] The Philosophy of Web Use.
by Laura Carlson 03 Aug '06

03 Aug '06

Ethan wrote: > Can you do me a favor and let me know how these examples work > for you? > > http://tool-man.org/examples/sorting.html Works great for able bodied mouse users. But how are people with mobility impairments like low dexterity (unable to use a pointing device like a mouse and instead must use keyboard or switch) able to use it? It doesn't seem to work via keyboard. WCAG Guideline 9. Design for device-independence: "Use features that enable activation of page elements via a variety of input devices. Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device -- mouse, keyboard, voice, head wand, or other. If, for example, a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with a keyboard or who is using some other non-pointing input device will not be able to use the form." [1] Best Regards, Laura [1] http://www.w3.org/TR/WCAG10/#gl-device-independence ___________________________________________ 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/

1 1

Re: [Mailman-Developers] HTML Headers
by Bryan Carbonnell 03 Aug '06

03 Aug '06

On 8/2/06, Andrew Nielson <a.nielson(a)griffith.edu.au> wrote: > Hi, > > I have written some code to allow Mailman to add a header.html file (if it > exists) to the top of each web page. > > Basically it checks a new option called WEB_HEADER_FILE which is set as > follows in mm_cfg.py: > WEB_HEADER_FILE = os.path.join(PREFIX, 'Mailman/header.html') > > I just wanted to know: > 1. Would you like me to submit this patch? > 2. Is $prefix/Mailman/header.html the correct place for a html file or > should we add a html directory or put it in the Cgi one? > 3. Would people like me to move the footer stuff out into another footer > file and do the same for it? Just to let you know, I created a patch for 2.1.7 (and 2.1.8 but I apparently haven't uploaded it to Sourceforge yet, oops) that does both sitewide headers and footer, not to mention makes the HTML code XHTML 1.1 compliant. It's patch #1415956 at Sourceforge. -- Bryan Carbonnell - carbonnb(a)gmail.com 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!"

1 0

Re: [Mailman-Developers] HTML Headers
by Mark Sapiro 03 Aug '06

03 Aug '06

Andrew Nielson wrote: > >I have written some code to allow Mailman to add a header.html file (if it >exists) to the top of each web page. > >Basically it checks a new option called WEB_HEADER_FILE which is set as >follows in mm_cfg.py: >WEB_HEADER_FILE = os.path.join(PREFIX, 'Mailman/header.html') > >I just wanted to know: >1. Would you like me to submit this patch? There is a Google Summer of Code intern working on major modification to the GUI, so your patch may well not be valid and/or relevant soon. You may wish to wait. If you wish to submit it anyway, you can do so at <http://sourceforge.net/tracker/?group_id=103&atid=300103> >2. Is $prefix/Mailman/header.html the correct place for a html file or >should we add a html directory or put it in the Cgi one? I think it should be a template, defaulting to an empty file or perhaps a file with an HTML comment documenting what it's for, and accessed via Utils.maketext(). How else would you address i18n issues in a multilingual site? >3. Would people like me to move the footer stuff out into another footer >file and do the same for it? No opinion. -- Mark Sapiro <msapiro(a)value.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

1 0

HTML Headers
by Andrew Nielson 02 Aug '06

02 Aug '06

Hi, I have written some code to allow Mailman to add a header.html file (if it exists) to the top of each web page. Basically it checks a new option called WEB_HEADER_FILE which is set as follows in mm_cfg.py: WEB_HEADER_FILE = os.path.join(PREFIX, 'Mailman/header.html') I just wanted to know: 1. Would you like me to submit this patch? 2. Is $prefix/Mailman/header.html the correct place for a html file or should we add a html directory or put it in the Cgi one? 3. Would people like me to move the footer stuff out into another footer file and do the same for it? Thanks, Andrew _____________________________________________________ Andrew Nielson Senior Systems Administrator Server Management Services Griffith University Email: A.Nielson(a)griffith.edu.au Web: http://www.griffith.edu.au/ppages/A_Nielson/ _____________________________________________________

1 0

Re: [Mailman-Developers] Turning off dynamic JavaScript
by Laura Carlson 01 Aug '06

01 Aug '06

--On Wednesday, July 5, 2006 8:54 PM +0200 emf wrote: > Are you suggesting I provide *no* link for the > screen-reader-with-javascript client and let them at some point > figure out that they're not seeing what's going on and thus turn off > javascript? > > That seems like a worse solution. I'm suggesting that javascript is fine to use for progressive enhancement but not for core functionality. Javascript should be used to enhance the usability, _if_ it doesn't negatively affect accessibility. A Javascript dependent app is just not accessible. But like it says in 6.3 of WCAG 1.0, if it is not possible to make pages accessible when scripts, applets, or other programmatic objects are turned off or not supported, the fallback is to provide equivalent information on an alternative accessible page. SitePoint's JavaScript Anthology chapter on JavaScript and accessibility that features a lot of test results with different screen readers, but I don't see that as much more use than a DHTML script that was tested in 1999 on Netscape and IE - by making your DHTML accessibility dependent on the user agent - regardless of screen reader or browser - you make it easily outdated. The problem is not only users of assistive technology, it is about availability as well. What if I work in a high security environment where my employer turns off JavaScript or filters it out via a proxy by default? What if I am somewhere without internet access on the ground and want to use my mobile or satellite phone to reach an app? In both Section 508 and WCAG 1.0 a separate text only version is not considered an accessible solution. Basically the requirements state that the author has determined that the primary site CANNOT be made accessible, and the text only site provides some kind of second class access to the content. Creating a text-only version of a web site should be done when there is no other way to make the content accessible, or when it offers significant advantages over the main version. And then the text-only version needs to provide the functionality equivalent to that of the main version. Some thing to consider with separate versions: Text-only versions are rarely totally equivalent in content to the "real" version. They often do not fully convey content and its context. They effectively segregate the audience they are targeted at. When there is a text-only version available, developers sometimes do not make the "real" version accessible. >From a maintenance view, creating a text-only page for every Web page is twice the work. Invariably, the text version is going to be out of sync with regular content. This then creates an accuracy problem. The accessible version is often hidden behind its inaccessible counterpart. People needing to use the accessible version of the website still need to be able to deal with the inaccessible one. They have to search through an inaccessible page to find the link to the text-only page. This problem could be reduced by ensuring that the "skip to accessible version" link is the first piece of information on a page. Ethan, have you considered making the main site not rely on JavaScript for functionality and having a link to a JavaScript enhanced version, so the accessible version is not hidden behind its inaccessible counterpart?...Or you might want to consider this approach: - make it work without JavaScript - add event handlers or even an AJAX layer to make it work more smoothly - give the user the option to use one interface or the other - as most web apps require login and have a defined user journey this is a lot easier, as visitors are not likely to enter in any of the pages like they do in a web site. Best regards, Laura ___________________________________________ 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/

7 25

Bounces, Pickles, Coding Styles Oh My
by emf 01 Aug '06

01 Aug '06

Calloo Callay! So I'm spelunking about. I don't like the way the current UI doesn't tell the admin about bounciness of users, so I was looking to see what is known. After some non-trivial meditation on BounceRunner.py I think I know the difference between verp_probe and verp_bounce, despite not quite knowing what VERP means, the comment string for the two functions being identical, and the bodies of them being identical as well save a tiny little memory stanza. Would someone be willing to change verp_probe's docstring to more clearly illustrate its function? Also, I'm finding a fair number of files that aren't pep8/styleguide.txt happy. anyone care if I at least correct tab/space mixing, and/or make it otherwise style-guide correct? As much as I appreciate the principles of code-hiding, it's been a bit of a pain to use the interpreter to figure out what is stored in a pickle. Since I can't read the pickle file with my eyes, perhaps a little less obscuration might be OK? Like, list.members['i(a)mindlace.net'] doesn't work. In fact, I can't find any function that gives me a member in its entirety. It would help me if I could just see the underlying data; any suggestions on how? ~ethan

3 3