Comments on: Current browsers and the User Agent Accessibility Guidelines 1.0 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/ Working together for standards Wed, 27 Mar 2013 12:19:03 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Chris PKV http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-58260 Chris PKV Sun, 15 Jul 2007 11:08:53 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-58260 @ bruce This I think should be part of the developing on the barrier-free browsing. As I know from several partners and friends we can't anticipate when and if MS will react and build their IE to display titles (for example) in the required way. @ bruce

This I think should be part of the developing on the barrier-free browsing. As I know from several partners and friends we can’t anticipate when and if MS will react and build their IE to display titles (for example) in the required way.

]]> By: WCAG Samurai Errata Review « WCAG Samurai Peer Review http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-58016 WCAG Samurai Errata Review « WCAG Samurai Peer Review Thu, 07 Jun 2007 06:30:36 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-58016 [...] I don’t think it is wrong to revise the guidelines in this way, assuming that there is some pressure on people producing user-agents to make appropriate updates. [...] [...] I don’t think it is wrong to revise the guidelines in this way, assuming that there is some pressure on people producing user-agents to make appropriate updates. [...]

]]> By: Robert Wellock http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-58008 Robert Wellock Wed, 06 Jun 2007 11:12:17 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-58008 Basically it means delivering the document with a text readable source. Furthermore also having the "fallback" option of reading the original "source code" rather than only being able to view the generated styled markup output of a browser rendered page. Basically it means delivering the document with a text readable source. Furthermore also having the “fallback” option of reading the original “source code” rather than only being able to view the generated styled markup output of a browser rendered page.

]]> By: Beni http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-57998 Beni Mon, 04 Jun 2007 12:57:39 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-57998 Hi Patrick, I’m a little bit confused about the Part 2.2 in your Article “Provide text view (P1) / The standard “view source” should satisfy this checkpoint.”, maybe my English is not good enough, can someone explain me what is mean with The standard “view source”. Thanks, Beni Hi Patrick,

I’m a little bit confused about the Part 2.2 in your Article “Provide text view (P1) / The standard “view source” should satisfy this checkpoint.”, maybe my English is not good enough, can someone explain me what is mean with The standard “view source”.

Thanks,
Beni

]]> By: bruce http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-57947 bruce Mon, 21 May 2007 11:15:52 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-57947 Great article, Pat. The lack of keyboard access to the title attribute is particularly galling, as it means that you can't rely on the title attribute to inform a user that a link opens a new window as WCAG requires; the keyboard user will never see that title. I've got no idea why the browser manufacturers can't sort this out. And, of course, who can forget <a href="http://juicystudio.com/article/ie-keyboard-navigation.php" rel="nofollow">Internet Explorer's shocking support for keyboard navigation of in-page links</a>. Great article, Pat.

The lack of keyboard access to the title attribute is particularly galling, as it means that you can’t rely on the title attribute to inform a user that a link opens a new window as WCAG requires; the keyboard user will never see that title. I’ve got no idea why the browser manufacturers can’t sort this out.

And, of course, who can forget Internet Explorer’s shocking support for keyboard navigation of in-page links.

]]> By: Gérard Talbot http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/comment-page-1/#comment-57945 Gérard Talbot Mon, 21 May 2007 04:39:41 +0000 http://www.webstandards.org/2007/05/20/current-browsers-and-the-user-agent-accessibility-guidelines-10/#comment-57945 Great article (full version) from P. Lauke; I appreciated it. Things that are missing, either in the UAAG 1.0 guidelines or in the article itself: - allow user agents to override attributes like noresize (frame), scrolling=no (frame), frameborder=0 (frame): it's mentioned in the techniques (section 3.7) - non-resizable secondary window (resizable=no in 3rd parameter of window.open function), - non-scrollable secondary window (scrollbars=no in 3rd parameter of window.open function), - allow easy and convenient override (or prevention) of any removal of chrome (toolbars or functionality) of secondary window (javascript-initiated created secondary window) Another example. In MSIE 6+, an user can not remove the menubar of a normal, standard, non-script-initiated window but a javascript author can remove it in a script-initiated secondary window: a blatant, pure non-sense contradiction where the author has more power than the user. Firefox and Seamonkey allow a lot of control to users but the user interface (about:config) allowing granular control is far from being an obvious one to figure out: which property does what or controls which feature. One needs to carefully read a long knowledge base article on the attributes/properties configurable in about:config. It would be interesting to measure the support and compliance of each major browser vendor (Microsoft, Mozilla, Opera, Safari) with their main browser regarding the UAAG 1.0 guidelines. It would show how far they are away from a perfect compliance, therefore showing how much they care about accessibility and would also show how far they are from each other. Gérard Great article (full version) from P. Lauke; I appreciated it.

Things that are missing, either in the UAAG 1.0 guidelines or in the article itself:

- allow user agents to override attributes like noresize (frame), scrolling=no (frame), frameborder=0 (frame): it’s mentioned in the techniques (section 3.7)

- non-resizable secondary window (resizable=no in 3rd parameter of window.open function),

- non-scrollable secondary window (scrollbars=no in 3rd parameter of window.open function),

- allow easy and convenient override (or prevention) of any removal of chrome (toolbars or functionality) of secondary window (javascript-initiated created secondary window)

Another example. In MSIE 6+, an user can not remove the menubar of a normal, standard, non-script-initiated window but a javascript author can remove it in a script-initiated secondary window: a blatant, pure non-sense contradiction where the author has more power than the user.

Firefox and Seamonkey allow a lot of control to users but the user interface (about:config) allowing granular control is far from being an obvious one to figure out: which property does what or controls which feature. One needs to carefully read a long knowledge base article on the attributes/properties configurable in about:config.

It would be interesting to measure the support and compliance of each major browser vendor (Microsoft, Mozilla, Opera, Safari) with their main browser regarding the UAAG 1.0 guidelines. It would show how far they are away from a perfect compliance, therefore showing how much they care about accessibility and would also show how far they are from each other.

Gérard

]]>