Re: [WSG] attribute selectors to target external and internal links

[tee]

 
On Oct 22, 2010, at 5:46 PM, Jason Arnold wrote:
> Unless I'm misunderstanding your question all you need to do is style
> your a tags this way in this order to get the right style on the right
> links:
> 

Re-arrange the order that is!!! 

Now I feel like the simpleton who tried enter the room with a long  stick 
holding horizontally.

tee

> a { style whatever the default style you want }
> a[href^="http"] { style whatever style you want for all external links }
> a[href*="sitethatisnotanexternalsite.com"] { style should be the same
> styles used in the a{} style}
> 
> the above order of rules will style external and internal links
> differently and won't fail and if there are additional domains that
> you want styled the same as the internal links you just keep adding
> a[href*="siteyouwanttoadd.com"] { styling} to the bottom of the list.
> Keep adding them to the bottom is the key here.



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

Re: [WSG] attribute selectors to target external and internal links

[Jason Arnold]

On Fri, Oct 22, 2010 at 3:57 PM, tee  wrote:
> Unless I am missing the obvious, this wouldn't work because I have no way to 
> know what external links client's will link to. I need a method that wouldn't 
> fail.
>

Unless I'm misunderstanding your question all you need to do is style
your a tags this way in this order to get the right style on the right
links:

a { style whatever the default style you want }
a[href^="http"] { style whatever style you want for all external links }
a[href*="sitethatisnotanexternalsite.com"] { style should be the same
styles used in the a{} style}

the above order of rules will style external and internal links
differently and won't fail and if there are additional domains that
you want styled the same as the internal links you just keep adding
a[href*="siteyouwanttoadd.com"] { styling} to the bottom of the list.
Keep adding them to the bottom is the key here.


-- 

Jason Arnold
http://www.jasonarnold.net



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

Re: [WSG] attribute selectors to target external and internal links

[tee]

Unless I am missing the obvious, this wouldn't work because I have no way to 
know what external links client's will link to. I need a method that wouldn't 
fail. 

tee

On Oct 22, 2010, at 4:54 AM, designer wrote:

> Forgive me if I'm missing the point here, but if you use:
> 
> a {
> color : red;
> text-decoration : none;
> border : none;
> }
> a[href*="site1"] {
>  color: #f00;
>  background: #555;
> }
> a[href*="site2"] {
>  color: #00f;
>  background: #eee;
> }
> a[href*="site3"] {
>  color: #0f0;
>  background: #ff0;
> }
> 
> It works for me. More importantly, it ignores any links containing "site", so 
> in other words, it really does have to be the full domain for it to work. You 
> can see this test here:
> 
> http://www.betasite.fsnet.co.uk/gam/attribute_selectors_external.html



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

Re: [WSG] Accessibility Testing

[Richard R. Hill]

I general, I advise designers to apply the standards (W3C, 508 … Whatever they 
have chosen) as diligently as possible keeping in mind the the intent of the 
standards (rather than just meeting the guidelines as worded). It is up to 
browser technology to also adhere to the standards. Theoretically, that should 
provide visitors an appropriate experience regardless of their disability.  
There is no way anyone can test effectively for all possible disabilities, even 
with "expert" human testers.

First, the testers must be trained to remove personal bias (a preference for 
navigation placement for instance) from actual accessibility issues.

Second, you can't possibly afford to test against all possible disability 
combination ( not JST blindness but perhaps low vision with arthritis, color 
blindness with hearing impairment or impairment or ).

 The intent of the standards is to provide the largest number of developers 
guidelines they can adopt to make their sites as universally usable by the 
widest number of user possible. And to provide browser (and other 
software/hardware) manufacturers guidelines on how to develop client technology 
that will provide an appropriate user experience.

Will this work perfectly?  No. Where shortfalls are identified, the standards 
will be enhanced (hopefully). In fact there is no single standard. W3C has 
multiple flavors. Which standard is used also impacts the degree of 
accessibility. So, if an organization chose WCAG 2 A sat the standard, 
obviously, their sites will not be as usable for visitors need a greater amount 
of accommodation (say WCAG 2 AA or AAA).

That said, am I against user testing?  Not at all.  If it is available to you, 
use it.  It can only help.  Should lack of such a resource prevent you from 
crafting accessible content?  Not at all.

By the by, even when testing content, use as many tools as you can.  They all 
report different results, which can often be enlightening.

Finally, the http://amnestyshop.org.uk/christmas-2010.html page has 
accessibility issues (forms mislabeled, fiedlsets with no legend, reliance on 
javascript to provide menu access, links with same label that have different 
target), no navigation skipping mechanism).  Depending on the tool I use, I get 
109 issues- Parsing (use of &): 3, HTML: 57, WCAG v2 A: 49.  SO, the page has 
issues that can be detected.  As far as how easy it is to navigate, most of the 
main elements have headers and this are used in a mostly correct fashion, so a 
browser that can dew]al correctly with headers allows a visitor to easily(?) 
move through the content (better with a skip nav).
–––
Rick Hill

From: Steve Green 
mailto:steve.gr...@testpartners.co.uk>>
Reply-To: "wsg@webstandardsgroup.org" 
mailto:wsg@webstandardsgroup.org>>
Date: Fri, 22 Oct 2010 07:27:41 -0700
To: "wsg@webstandardsgroup.org" 
mailto:wsg@webstandardsgroup.org>>
Subject: RE: [WSG] Accessibility Testing

-Original Message-
From: li...@webstandardsgroup.org 
[mailto:li...@webstandardsgroup.org] On Behalf Of Lesley Lutomski
Sent: 22 October 2010 14:49
To: wsg@webstandardsgroup.org
Subject: [WSG] Accessibility Testing

On 20/10/10 21:13, Nick Stone wrote:

> Does anyone have suggestions on how to obtain website usability feedback  > 
> from various members of the disabled community?


Kevin Ireson replied with some helpful comments, but I think Nick's main point 
was that there is no substitute for testing by real people with real 
disabilities and that can be very hard to achieve.  I can try to make my sites 
accessible to someone using a screen reader, for example, but as I don't use 
one myself I'm only guessing at how a real user would approach the site.  
Accessibility testing software is helpful, but doesn't test for all types of 
disability.

For example, there are a wide range of conditions that result in impaired 
movement, including things as common as arthritis.  These can make using mouse 
and keyboard both quite difficult.  With this in mind, might I suggest you 
visit http://amnestyshop.org.uk/christmas-2010.html
and see if you find any potential problems.  Would your normal accessibility 
testing have thrown up these issues, or not?  (I apologise for picking on 
Amnesty; it has the most extreme version I know of a common problem.)

I do know of one organisation that arranges site testing by disabled people, 
but their charges are beyond the budget of any of my clients.
Any ideas, anyone?

Thank you.

Lesley

---

Since you ask, we arrange user testing with disabled participants and assistive 
technologies. It's not cheap but we are more cost-effective than the larger 
organisations such as RNIB, Shaw Trust and AbilityNet.

An intermediate option is an expert review by a consultant with experience of 
user testing, and we do t

RE: [WSG] Accessibility Testing

[Steve Green]

-Original Message-
From: li...@webstandardsgroup.org [mailto:li...@webstandardsgroup.org] On 
Behalf Of Lesley Lutomski
Sent: 22 October 2010 14:49
To: wsg@webstandardsgroup.org
Subject: [WSG] Accessibility Testing

On 20/10/10 21:13, Nick Stone wrote:

 > Does anyone have suggestions on how to obtain website usability feedback  > 
 > from various members of the disabled community?


Kevin Ireson replied with some helpful comments, but I think Nick's main point 
was that there is no substitute for testing by real people with real 
disabilities and that can be very hard to achieve.  I can try to make my sites 
accessible to someone using a screen reader, for example, but as I don't use 
one myself I'm only guessing at how a real user would approach the site.  
Accessibility testing software is helpful, but doesn't test for all types of 
disability.

For example, there are a wide range of conditions that result in impaired 
movement, including things as common as arthritis.  These can make using mouse 
and keyboard both quite difficult.  With this in mind, might I suggest you 
visit http://amnestyshop.org.uk/christmas-2010.html
and see if you find any potential problems.  Would your normal accessibility 
testing have thrown up these issues, or not?  (I apologise for picking on 
Amnesty; it has the most extreme version I know of a common problem.)

I do know of one organisation that arranges site testing by disabled people, 
but their charges are beyond the budget of any of my clients. 
Any ideas, anyone?

Thank you.

Lesley

---

Since you ask, we arrange user testing with disabled participants and assistive 
technologies. It's not cheap but we are more cost-effective than the larger 
organisations such as RNIB, Shaw Trust and AbilityNet.

An intermediate option is an expert review by a consultant with experience of 
user testing, and we do this when time and/or budget are limited. Obviously it 
doesn't pick up all the issues that user testing does, but it's a fraction of 
the cost and it picks up enough issues to be worthwhile.

We also provide screen reader training for developers and testers who want an 
insight into how people use screen readers. This course teaches enough to do 
some basic  testing and provides a lot of guidelines for accessible design 
(beyond compliance with WCAG).

If even this is not affordable, there's no reason why you can't arrange your 
own user testing. At first it takes a bit of work to find participants, and you 
will have to pay them an incentive (typically £20 to £30 per hour plus travel). 
In most cases you can do the testing in people's homes, so you don't need any 
equipment or software. You will need to read up on how to run user tests to get 
the best results, but it's not rocket science and there is lots of guidance on 
the web. There are quite a few disability support groups who will help you find 
participants, but be aware that those who offer a testing service (such as the 
three I mentioned above) tend not to be cooperative.

Steve Green
Managing Director
Test Partners Ltd


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

[WSG] Accessibility Testing

[Lesley Lutomski]

On 20/10/10 21:13, Nick Stone wrote:

> Does anyone have suggestions on how to obtain website usability feedback
> from various members of the disabled community?


Kevin Ireson replied with some helpful comments, but I think Nick's main 
point was that there is no substitute for testing by real people with 
real disabilities and that can be very hard to achieve.  I can try to 
make my sites accessible to someone using a screen reader, for example, 
but as I don't use one myself I'm only guessing at how a real user would 
approach the site.  Accessibility testing software is helpful, but 
doesn't test for all types of disability.


For example, there are a wide range of conditions that result in 
impaired movement, including things as common as arthritis.  These can 
make using mouse and keyboard both quite difficult.  With this in mind, 
might I suggest you visit http://amnestyshop.org.uk/christmas-2010.html 
and see if you find any potential problems.  Would your normal 
accessibility testing have thrown up these issues, or not?  (I apologise 
for picking on Amnesty; it has the most extreme version I know of a 
common problem.)


I do know of one organisation that arranges site testing by disabled 
people, but their charges are beyond the budget of any of my clients. 
Any ideas, anyone?


Thank you.

Lesley


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

Re: [WSG] attribute selectors to target external and internal links

[Rob Crowther]

tee wrote:

I have this:
a[href*="site.com"] {color: #e21;background: #555;}

Then I added this thinking this will tell the browser to give external link 
with a white background, but all links are with white background.

[href^="http"]{color: #e21;background: #fff;}

The http overrules the one with "site.com" value.

And if you put the rules in the opposite order, the site.com one will 
override the http one, just the same as if you had two rules for h1 or p 
in your stylesheet.


Rob


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

Re: [WSG] attribute selectors to target external and internal links

[designer]

Forgive me if I'm missing the point here, but if you use:

a {
 color : red;
 text-decoration : none;
 border : none;
}
a[href*="site1"] {
  color: #f00;
  background: #555;
}
a[href*="site2"] {
  color: #00f;
  background: #eee;
}
a[href*="site3"] {
  color: #0f0;
  background: #ff0;
}

It works for me. More importantly, it ignores any links containing "site", 
so in other words, it really does have to be the full domain for it to work. 
You can see this test here:


http://www.betasite.fsnet.co.uk/gam/attribute_selectors_external.html

HTH,

Bob
- Original Message - 
From: "tee" 

To: 
Sent: Friday, October 22, 2010 9:22 AM
Subject: Re: [WSG] attribute selectors to target external and internal links



[snip]




The http overrules the one with "site.com" value.


Unless I can be certain external links will never share a same word with the 
site domain name, it's not very safe to use the attributes.


tee









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

[WSG] Out of Office AutoReply Re: WSG Digest

[Ryan Blunden]

I am currently out of the office until 25 October 2010. For any issues
please call me on 0413 214 666, alternatively I will respond to your
emal on my return.

Thanks
Luis Landaverde

-- 


*Ryan Blunden*
Web Specialists Tech Lead

*Mavericks Online - Web Solutions*
Flight Centre Limited
545 Queen St, Level 4, Brisbane QLD 4000

*Follow Flight Centre on Twitter*  - *Become a Fan of
Flight Centre on Facebook *


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

Re: [WSG] attribute selectors to target external and internal links

[tee]

>>> 
> 
> Umm. In your particular case, 'domain-name' would be 'site.com'. I
> believe Thierry meant you to use -
> 
> a[href*="site.com"] {...}
> 
> Is that what you tried?
> 
> Cordially,
> David
> --


I thought I did, but I guess I didn't as I kept thinking absolute path 
therefore it must start with "http://";

It overwrites [href^="http"] rule though.

I have this:
a[href*="site.com"] {color: #e21;background: #555;}

Then I added this thinking this will tell the browser to give external link 
with a white background, but all links are with white background.

[href^="http"]{color: #e21;background: #fff;}

The http overrules the one with "site.com" value.

According to the specs,
[att^=val]
Represents an element with the att attribute whose value begins with the prefix 
“val”.

[att$=val]
Represents an element with the att attribute whose value ends with the suffix 
“val”.

[att*=val]
Represents an element with the att attribute whose value contains at least one 
instance of the substring “val”.

Unless I can be certain external links will never share a same word with the 
site domain name, it's not very safe to use the attributes.

tee




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