RE: [WSG] Right div dropping below left floated div when browser resized

[Kepler Gelotte]

> The problem is that when the browser window is reduced in
> size, to the point that the table can no longer shrink to fit
> inside the available space, the table (but not the whole
> right div) drops down so that the top of the table is in line 
> with the bottom of the left navigation div. This problem 
> occurs in IE6 but not IE7 or Firefox. 

Hi Stevio,

I think the trick is to take the table out of the normal flow by floating it
if it is in IE6. Then wrap the table with a positioned relative div that
takes close to the full width of the right container. This keeps text below
from creeping up the side. 

Here is a test page I created that seems to do what you want:

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd";> 
http://www.w3.org/1999/xhtml"; lang="en" xml:lang="en"> 
 
 
Example 
 
 

body {
 border: solid red 1px;
}
#navigation {
 float: left;
 width: 180px;
 margin-top: 20px;
 margin-bottom: 10px;
 margin-left: 9px;
 margin-right: 0px;
 padding-left: 1px;
 padding-right: 1px;
 background: #FF;
 border-top: 2px solid #336699;
 border-bottom: 2px solid #336699;
}
#mainbody {
 position: relative;
 margin-left: 210px;
 margin-top: 20px;
 margin-right: 20px;
 margin-bottom: 20px;
 padding: 0;
 border: solid black 1px;
} 
#mainbody h2 {
 margin: 0;
 padding: 0;
 background-color: #0f0;
}
.tablelist {
 position: relative;
 overflow: hidden;
 width: 100%;
 _width: 95%; /* may have to play with this value */
}
.tablelist table {
 _float: left;
 margin: 0;
 padding: 0;
 background-color: #ff0;
}

 
 



 
  Home
  About
  News
 



 My List
 
  
   Col 1Col 2Col 3
   123
  
 





Best regards,
Kepler Gelotte
Neighbor Webmaster, Inc.
156 Normandy Dr., Piscataway, NJ 08854
www.neighborwebmaster.com
phone/fax: (732) 302-0904



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***BEGIN:VCARD
VERSION:2.1
N:Gelotte;Kepler;;Mr.
FN:Kepler Gelotte (kep...@neighborwebmaster.com)
ORG:Neighbor Webmaster
TITLE:Web Designer
TEL;WORK;VOICE:(732) 302-0904
TEL;WORK;FAX:(732) 302-0904
ADR;WORK:;;156 Normandy Dr;Piscataway;NJ;08854;United States of America
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:156 Normandy Dr=0D=0APiscataway, NJ 08854=0D=0AUnited States of America
URL;WORK:http://www.neighborwebmaster.com
EMAIL;PREF;INTERNET:kep...@neighborwebmaster.com
REV:20070415T052107Z
END:VCARD

RE: [WSG] Accessible websites (was: accessible free web hosting account)

[Jens-Uwe Korff]

Hi,

thank you for your thoughts and feedback.

> After all, the few people that do spend any time at all on making their 
> websites accessible, 
> probably aren't going to be experts in accessibility, so probably won't do a 
> very good job of it.  

Yes and no. If we had no pioneers which inherently cannot make a "very good 
job" we wouldn't have innovation.
I rather make a not-so-good attempt in accessibility than leaving it and wait 
for others to come up with something.

> FYI, when I click on "Low vision" and get the high-contrast stylesheet, that 
> right-most menu pick changes to 
> "High contrast" ...

I know. As I said we are in the process of changing "low vision" to "high 
contrast" and that's what you get in the interim. Sorry. Will be cleaned up in 
one of the future releases.

> it's terribly ironic that this menu pick becomes large enough for a person 
> with limited vision to read only after it's been selected.

Well, you know that you've got theory and practice. In theory I agree with you 
and would make the link large and contrasty. In practice however we are bound 
by the constraints of a design to which many groups have to say yay or nay. The 
above-the-fold area is the most competitive part of any design. 

Responding to Jim's comment about [people too proud to wear] glasses: You would 
be surprised how many people are in that very same situation. They make up a 
significant number who actually benefit from accessible websites.

> Is there any other strong arguments for making pages available, without 
> javascript enabled?

I'd like to know too. On the Sydney Morning Herald in June less than 0.5% of 
users had JS disabled. Maybe we should drop that support? Anyone willing to 
share their numbers/reasons?

Cheers,
 
Jens 
The information contained in this e-mail message and any accompanying files is 
or may be confidential. If you are not the intended recipient, any use, 
dissemination, reliance, forwarding, printing or copying of this e-mail or any 
attached files is unauthorised. This e-mail is subject to copyright. No part of 
it should be reproduced, adapted or communicated without the written consent of 
the copyright owner. If you have received this e-mail in error please advise 
the sender immediately by return e-mail or telephone and delete all copies. 
Fairfax does not guarantee the accuracy or completeness of any information 
contained in this e-mail or attached files. Internet communications are not 
secure, therefore Fairfax does not accept legal responsibility for the contents 
of this message or attached files.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Right div dropping below left floated div when browser resized

[Stevio]

Thanks Joseph, but I don't know the width however. The right width column 
varies according to the width of the browser and it's content.

Stephen

  - Original Message - 
  From: Joseph Taylor 
  To: wsg@webstandardsgroup.org 
  Sent: Tuesday, June 30, 2009 10:00 PM
  Subject: Re: [WSG] Right div dropping below left floated div when browser 
resized


  IE6 will drop your content down to a place where it'll fit.

  You need to do something like this:

  my_container {
min-width: XXpx;
_width: XXpx; /* just for IE6 */
   }

  IE6 needs specified width and then it'll behave like it was given a min-width.

  Joseph R. B. Taylor
  Designer / Developer
  --
  Sites by Joe, LLC
  "Clean, Simple and Elegant Web Design"
  Phone: (609) 335-3076
  Web: http://sitesbyjoe.com
  Email: j...@sitesbyjoe.com


  On 6/30/09 4:42 PM, Stevio wrote: 
I have two divs as follows (no link sorry, web page is protected) - a left 
div for navigation, a right div containing a header and table (with tabular 
data). 

The problem is that when the browser window is reduced in size, to the 
point that the table can no longer shrink to fit inside the available space, 
the table (but not the whole right div) drops down so that the top of the table 
is in line with the bottom of the left navigation div. This problem occurs in 
IE6 but not IE7 or Firefox. 

Any ideas how I can fix this so the table just stays in place like it 
should when the horizontal scrollbar appears? 

Code is below. Thanks. 
 

 
--content-- 
 

 
My List 
 
 
--table content-- 
 
 

CSS is: 
#navigation { 
float: left; 
width: 180px; 
margin-top: 20px; 
margin-bottom: 10px; 
margin-left: 9px; 
margin-right: 9px; 
padding-left: 1px; 
padding-right: 1px; 
background: #FF; 
border-top: 2px solid #336699; 
border-bottom: 2px solid #336699; 
} 
#mainbody { 
margin-left: 210px; 
margin-top: 20px; 
margin-bottom: 20px; 
margin-right: 20px; 
border: 0px solid black; 
} 


*** 
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm 
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm 
Help: memberh...@webstandardsgroup.org 
*** 



  ***
  List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
  Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
  Help: memberh...@webstandardsgroup.org
  ***

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Right div dropping below left floated div when browser resized

[Joseph Taylor]

IE6 will drop your content down to a place where it'll fit.

You need to do something like this:

my_container {
  min-width: XXpx;
  _width: XXpx; /* just for IE6 */
 }

IE6 needs specified width and then it'll behave like it was given a 
min-width.


Joseph R. B. Taylor
/Designer / Developer/
--
Sites by Joe, LLC
/"Clean, Simple and Elegant Web Design"/
Phone: (609) 335-3076
Web: http://sitesbyjoe.com
Email: j...@sitesbyjoe.com


On 6/30/09 4:42 PM, Stevio wrote:
I have two divs as follows (no link sorry, web page is protected) - a 
left div for navigation, a right div containing a header and table 
(with tabular data).


The problem is that when the browser window is reduced in size, to the 
point that the table can no longer shrink to fit inside the available 
space, the table (but not the whole right div) drops down so that the 
top of the table is in line with the bottom of the left navigation 
div. This problem occurs in IE6 but not IE7 or Firefox.


Any ideas how I can fix this so the table just stays in place like it 
should when the horizontal scrollbar appears?


Code is below. Thanks.



--content--



My List


--table content--



CSS is:
#navigation {
float: left;
width: 180px;
margin-top: 20px;
margin-bottom: 10px;
margin-left: 9px;
margin-right: 9px;
padding-left: 1px;
padding-right: 1px;
background: #FF;
border-top: 2px solid #336699;
border-bottom: 2px solid #336699;
}
#mainbody {
margin-left: 210px;
margin-top: 20px;
margin-bottom: 20px;
margin-right: 20px;
border: 0px solid black;
}


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

[WSG] Right div dropping below left floated div when browser resized

[Stevio]

I have two divs as follows (no link sorry, web page is protected) - a left 
div for navigation, a right div containing a header and table (with tabular 
data).


The problem is that when the browser window is reduced in size, to the point 
that the table can no longer shrink to fit inside the available space, the 
table (but not the whole right div) drops down so that the top of the table 
is in line with the bottom of the left navigation div. This problem occurs 
in IE6 but not IE7 or Firefox.


Any ideas how I can fix this so the table just stays in place like it should 
when the horizontal scrollbar appears?


Code is below. Thanks.



--content--



My List


--table content--



CSS is:
#navigation {
float: left;
width: 180px;
margin-top: 20px;
margin-bottom: 10px;
margin-left: 9px;
margin-right: 9px;
padding-left: 1px;
padding-right: 1px;
background: #FF;
border-top: 2px solid #336699;
border-bottom: 2px solid #336699;
}
#mainbody {
margin-left: 210px;
margin-top: 20px;
margin-bottom: 20px;
margin-right: 20px;
border: 0px solid black;
} 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites

[David Hucklesby]

Jens-Uwe Korff wrote:

Hi all,

I believe making sites accessible is very important.

We are all used to ramps near stairs, lifts near escalators, lowered 
curbs at intersections. We need to get used to "baking in" time into 
our projects for accessible elements.

[...]


I agree wholeheartedly. These improvements serve far more people than
those originally targeted, too. The cost should not be high, either - I
think it's more a mind-set than hard labor.

If I may make one suggestion: you could place a link to, say, the BBC
accessibility pages[1] and/or the RNIB "Surf Right" toolbar[2] on your
pages. That's what I plan to do, anyway.

[1] 
[2]


Cordially,
David
--


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

RE: [WSG] accessible free web hosting account

[Andreas Boehmer [Addictive Media]]

> -Original Message-
> From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org]
> On Behalf Of Craig Henneberry
> Sent: Friday, 26 June 2009 1:46 PM
> To: wsg@webstandardsgroup.org
> Subject: RE: [WSG] accessible free web hosting account
> 
> Andrew Stewart wrote:
> 
> >Most people
> >would love to make every website 100% accessible to everyone. However,
> >if it costs a lot of time and money, but returns very little revenue
> >from the small number of users with screen readers, then why should
> >companies bother?

[...]

> Besides, Australian law makes web accessibility a mandatory
> requirement. Have you heard of the "Bruce Maguire vs. SOCOG" (Sydney
> Organising Committee for the Olympic Games) case of 1999?

If every company really were equally punished for making an inaccessible
website, there would be something majorly wrong with our law. I agree with
Andrew that there are certain lines that need to be drawn in regards to how
feasible it is to make a website accessible. 

Just imagine every business in Australia that doesn't have wheelchair access
would be punished by law for being inaccessible! None of the little stores
would ever have a chance to meet this requirements and it would be
ridiculous to expect otherwise. Of course we could also say that "A shop
that is accessible using assistive technology (a wheelchair) is more
accessible to its wider audience". But really, the expenditure would far
outweigh the benefit for the small stores.

Yes, a line needs to be drawn. A government or publicly funded website needs
to be of course accessible, as much as can be expected (this could be
interpreted as being WCAG 2.0 Level A compliant. Or Level AA? Or Level
AAA?). 

But let's take the example of small companies creating a free service
website. Let's assume somebody creates this really cool web application that
is just awesome and does amazing things. And he or she offers it for free to
the community, because that's just the type of person they are. Should they
be punished for having a web service that is inaccessible? Are they being
confronted with the options: make your site accessible or get rid of it? Is
somebody going to sue them for offering a free service to the community that
some of us unfortunately cannot access but others can?

So you say that it's something different if it's a free web service. Let's
assume there's a small, local shop that sells toys. They've been in business
for many years, making just enough money to get by. The owner of the shop
thinks it'd be cool to advertise their products online. So he sits down and
makes a website in ImageReady. Yes, IMAGEREADY! It's all pictures, not a
single ALT tag. But the website works, and he puts it online and it creates
more income for him. Who's going to come and sue him for having a website
that is inaccessible? 

Yes, of course it's easy for some of us to create accessible sites, but we
need to be realistic here. For some organisations it is just not worth
spending the time on making sites accessible. 

And the Australian law does take this into account. A website needs to be as
accessible as can be reasonably expected. It was reasonable to expect that
SOCOG would have a WCAG compliant website. It is not reasonable to expect
that every Australian website out there is accessible, whether they sell
products, offer services, or just provide John Doe's personal animated gif
collection.

So, coming back to the original question: who's job is it to ensure
accessibility? The web developers or the assistive technology companies? The
shop keepers or the companies that create wheelchairs? 

Of course it's a mixture of both of them. Companies that create wheelchairs
try to make them as modern and useful as possible. It's the same for the
companies that create other assistive technologies such as screen readers. 

And the web developers or shopkeepers try to make their stores as accessible
as can be expected from them. If you go to a university building, you can
surely expect there to be wheel chair ramps and lifts. If you go to the
SOCOG website you can surely expect it to pass Priority 1 of WCAG 1. If you
go to the Chinese Restaurant around the corner and there are 20 stairs and
no lifts, then you will just have to go to another place to eat. And if you
go to Fred's Toy Store website and none of the pictures have ALT tags, then
you just go to another website that provides a better service. 

That's why we love the web: it's so large that there are good chances we
will find what we need if not from one provider then from another.
 

__ Information from ESET NOD32 Antivirus, version of virus signature
database 4198 (20090629) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@

Re: [WSG] javascript and accessibility [was: Accessible websites]

[Paul Novitski]

At 6/30/2009 01:41 AM, Mathew Robertson wrote:

> I like to think that this is where web
> development should begin, with JavaScript added to enhance, not to
> provide core functionality.

Why?

Most modern accessibility aids (eg: font increase, JAWS, etc) use an 
existing browser, which can handle javascript.  Google processes 
javascript and RDF tags.


I've only ever heard a single argument as to why javascript-disabled 
should apply as a baseline for websites, specifically: if some 
percentage has JS disabled, you would be losing those visitors -> 
which of course can be measured.


Is there any other strong aruguments for making pages available, 
without javascript enabled?



One example of why support for non-JS UAs is a good idea is form 
validation. Assuming that all requesting user agents are running 
JavaScript and therefore will be forced to submit a valid form is 
like barring the front door of the bank but leaving the back door 
wide open. Since you need server-side validation for fundamental 
security, build that first, then add client-side validation to speed 
things up for users running JavaScript.


Read the rationales & arguments for progressive enhancement & 
graceful degradation. Rather than creating pages that depend on 
specialty technologies that don't have universal coverage, and then 
back-filling (when & if there's time!) to support Those Other user 
agents, the PE approach is to build sites that work in all user 
agents and then add enhancements to enrich the experience of visitors 
using special features. That way you don't have to try to calculate 
how many people you're shutting out and whether you can live with 
that on your conscience and on your bottom line.


User agents that don't support JavaScript include search engines, 
many new mobile devices, browsers whose users have turned off 
JavaScript, and browsers with JS enabled but situated behind 
corporate firewalls that strip scripts out of incoming pages. Can you 
really count them? Will you really do so? If you do, what conclusions 
will you draw from the numbers? What percentage of visitors (human 
and otherwise) to a site do you consider expendable? What kind of 
online business model includes the deliberate alienation of some 
percentage of prospective visitors or customers?


The attitude that we should shut out minority visitors is born from 
the assumption that it's expensive to cater to them, which of course 
it is if you try to back-pedal for them in the final stages of 
development instead of including them from the beginning. It's always 
more expensive to retrofit than to incorporate something into the 
original design. It amazes me that, decades after we've raised our 
consciousnesses around architectural accessibility and now commonly 
see ramps and Braille elevator controls and wheelchair-accessible 
bathroom stalls, we're grousing about minority support in website 
design where there aren't even any real materials used to build them. 
The main effort is one of shifting one's internal paradigm. That 
might not be easy, but it should be welcome exercise for thinking people.


This discussion is about accessibility to the extent that some 
assistive user agents are not JavaScript-enabled and even among those 
that are a huge number of JavaScript user interfaces require a lot of 
fine motor control on the mouse. At the same time, a) accessibility 
isn't just for disabled people, it's for everyone (just ask Jakob 
Nielsen), and b) this isn't all about accessibility, it's also about 
parseability by search engines and other software.


Google themselves recommend, "Use a text browser such as Lynx to 
examine your site, because most search engine spiders see your site 
much as Lynx would. If fancy features such as JavaScript, cookies, 
session IDs, frames, DHTML, or Flash keep you from seeing all of your 
site in a text browser, then search engine spiders may have trouble 
crawling your site."

- from Google.com > Webmaster guidelines > Technical guidelines
http://google.com/support/webmasters/bin/answer.py?answer=35769#2

Unlike most search engines that don't interpret JavaScript at all, 
Google attempts to process inline JavaScript embedded in the HTML but 
not external .js files. This means that if you want to build a site 
that depends on JavaScript for core functionality and content and 
have it be indexable by Google, you cannot separate the content & 
behavior development layers. Even if I were motivated to hide 
hyperlinks from humans not using JavaScript and from search engines 
other than Google, I would consider the prospect of writing inline 
code too expensive, inefficient, non-modular, unreusable, and 
altogether distasteful to be worth the effort. Why would anyone 
knowingly go there?


If you don't supply identical content to JavaScript-enabled and 
-disabled user agents, Google will consider that cloaking -- 
directing different content to search engines than to human users -- 
which can get 

[WSG] javascript and accessibility [was: Accessible websites]

[Mathew Robertson]

> >I found that some of these elements take quite some time to 
> >integrate. Creating high-contrast CSS can take up to a day (or more 
> >if you're new to it), non-Javascript states usually more than an 
> >hour because you also have to edit the script.

> By "non-Javascript states" do you mean that the website should work 
> in the absence of JavaScript? I like to think that this is where web 
> development should begin, with JavaScript added to enhance, not to 
> provide core functionality.

Why?

Most modern accessibility aids (eg: font increase, JAWS, etc) use an existing 
browser, which can handle javascript.  Google processes javascript and RDF tags.

I've only ever heard a single argument as to why javascript-disabled should 
apply as a baseline for websites, specifically: if some percentage has JS 
disabled, you would be losing those visitors -> which of course can be measured.

Is there any other strong aruguments for making pages available, without 
javascript enabled?

regards
Mathew Robertson

PS. Gut-feel tells me that non-JS should work, so thats how I prefer to code.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites (was: accessible free web hosting account)

[Paul Novitski]

At 6/29/2009 11:46 PM, Jens-Uwe Korff wrote:
I found that some of these elements take quite some time to 
integrate. Creating high-contrast CSS can take up to a day (or more 
if you're new to it), non-Javascript states usually more than an 
hour because you also have to edit the script.


By "non-Javascript states" do you mean that the website should work 
in the absence of JavaScript? I like to think that this is where web 
development should begin, with JavaScript added to enhance, not to 
provide core functionality.



For an example of a high-contrast version may I suggest to check out 
the Sydney Morning Herald's Travel section 
(http://www.smh.com.au/travel/). Click on "Low vision" in the 
navigation bar (We're going to replace "low vision" with "high 
contrast" since the former can be perceived as discriminatory). The 
styles you see then have been developed together with a vision-impaired person.


FYI, when I click on "Low vision" and get the high-contrast 
stylesheet, that right-most menu pick changes to "High contrast" and 
is highlighted, indicating that I am now on the high-contrast page. I 
click it again and I return to the starting stylesheet and the menu 
pick changes to "Normal contrast."


This is inconsistent -- first you're using the menu pick as a sign 
post to another state, and then you're using it as a current state 
indicator. Was this deliberate? It feels broken to me. Usually I 
click on menu items in order to go to the named item or to invoke the 
named change. You're using the menu pick initially in this way, but 
after you begin using it, it becomes an indicator of the current 
state rather than a sign post pointing off-stage.


I would choose just one of those models, leaning toward sign post. If 
you want to indicate the current state, I would display both states 
and highlight the current one.


Also, to ditto Jim Croft, it's terribly ironic that this menu pick 
becomes large enough for a person with limited vision to read only 
after it's been selected.


Regards,

Paul
__

Paul Novitski
Juniper Webcraft Ltd.
http://juniperwebcraft.com 




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites (was: accessible free web hosting account)

[Andrew Stewart]

On 30 Jun 2009, at 16:46, Jens-Uwe Korff wrote:

For an example of a high-contrast version may I suggest to check out  
the Sydney Morning Herald's Travel section (http://www.smh.com.au/travel/ 
). Click on "Low vision" in the navigation bar (We're going to  
replace "low vision" with "high contrast" since the former can be  
perceived as discriminatory). The styles you see then have been  
developed together with a vision-impaired person.


They're not pretty, but usable.


I believe a better solution to this issue is to work at the level of  
the browser, or operating system, rather than on site by site basis.  
i.e creating really intelligent browser plug-ins or applications that  
are able to interpret the mess on the internet and make it more usable  
to all. This solution means that everyone could customise their  
experience to make it suitable for them. On the smh travel site you  
have only two options (normal and low vision) to cater for the many  
hundreds of levels of vision impairment. The current situation seems  
to be that most designers do nothing about accessibility, a few make  
an attempt and fail, but only a few get anywhere towards succeeding.


If a company/designer has a certain amount of time/money to spend on  
accessibility, perhaps the best way to spend it would be to donate it  
to free accessibility projects. I think this would probably have a  
greater positive effect on the web. After all, the few people that do  
spend any time at all on making their websites accessible, probably  
aren't going to be experts in accessibility, so probably won't do a  
very good job of it.


Perhaps the WSG would be a good institution for co-ordinating such a  
scheme for donating money to accessible software projects?


Andy

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***

Re: [WSG] Accessible websites (was: accessible free web hosting account)

[Jim Croft]

I think it is pretty good.

But one slight irony/anomaly - the 'low vision' link is in pretty
small font.  Took me a while to find it... time for new
glasses prescription

jim

On Tue, Jun 30, 2009 at 4:46 PM, Jens-Uwe
Korff wrote:
> Hi all,
>
> I believe making sites accessible is very important.
>
> We are all used to ramps near stairs, lifts near escalators, lowered curbs at 
> intersections. We need to get used to "baking in" time into our projects for 
> accessible elements.
>
> Such elements are hidden headings (to aid semantics), skip links (to aid 
> navigation), non-Javascript styles (to enable interaction with all content) 
> and also high-contrast style sheets for vision-impaired users.
>
>> I don't believe that integrating accessibility into a project adds a 
>> significant cost to a project anyway.
>
> I found that some of these elements take quite some time to integrate. 
> Creating high-contrast CSS can take up to a day (or more if you're new to 
> it), non-Javascript states usually more than an hour because you also have to 
> edit the script.
>
> If you haven't considered accessibility in your company before you'll find 
> that a lot of time goes by convincing the backing parties (Product Managers, 
> Project Managers) to take it on board.
>
> For an example of a high-contrast version may I suggest to check out the 
> Sydney Morning Herald's Travel section (http://www.smh.com.au/travel/). Click 
> on "Low vision" in the navigation bar (We're going to replace "low vision" 
> with "high contrast" since the former can be perceived as discriminatory). 
> The styles you see then have been developed together with a vision-impaired 
> person.
>
> They're not pretty, but usable.
>
> The biggest challenge with this kind of CSS is to keep up with development 
> and remind oneself to update the code. It's not perfect, but it's a start.
>
> Cheers,
>
> Jens
> The information contained in this e-mail message and any accompanying files 
> is or may be confidential. If you are not the intended recipient, any use, 
> dissemination, reliance, forwarding, printing or copying of this e-mail or 
> any attached files is unauthorised. This e-mail is subject to copyright. No 
> part of it should be reproduced, adapted or communicated without the written 
> consent of the copyright owner. If you have received this e-mail in error 
> please advise the sender immediately by return e-mail or telephone and delete 
> all copies. Fairfax does not guarantee the accuracy or completeness of any 
> information contained in this e-mail or attached files. Internet 
> communications are not secure, therefore Fairfax does not accept legal 
> responsibility for the contents of this message or attached files.
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
>
>



-- 
_
Jim Croft ~ jim.cr...@gmail.com ~ +61-2-62509499 ~
http://www.google.com/profiles/jim.croft

... in pursuit of the meaning of leaf ...


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***