E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 7 (In chronological order)

From: Dennis Deacon
Date: Thu, Feb 25 2016 4:55AM
Subject: Block Links & Other Validation Issues in XHTML 1.0 Transitional
No previous message | Next message →

We use block links throughout our website for advertisements, offers, etc.
I've recently learned that block links are officially only supported
starting with HTML5. So while the web browser handles them fine
(seemingly), and only irritate screen reader users (unfortunately), this
technically fails validation. How does this relate to the "R" in WCAG's
POUR principles (Robust)?

I see mention that under parsing, web pages should validate, with the HTML
conforming to specifications. Block links under a XHTML doctype would fail
this. Does this mean these pages fail compliance (especially if mandated)?
Additionally, if a page has validation errors, would this be an
accessibility compliance concern?

--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Steve Faulkner
Date: Thu, Feb 25 2016 5:01AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | Next message →

Hi Dennis first question is why use XHTML transitional doctype and not
HTML5 doctype?

use of XHTML doctype offers no practical benefits and only makes finding
HTML conformance errors that need to be fixed, to improve user experience,
harder to find.


--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 25 February 2016 at 11:55, Dennis Deacon < = EMAIL ADDRESS REMOVED = > wrote:

> We use block links throughout our website for advertisements, offers, etc.
> I've recently learned that block links are officially only supported
> starting with HTML5. So while the web browser handles them fine
> (seemingly), and only irritate screen reader users (unfortunately), this
> technically fails validation. How does this relate to the "R" in WCAG's
> POUR principles (Robust)?
>
> I see mention that under parsing, web pages should validate, with the HTML
> conforming to specifications. Block links under a XHTML doctype would fail
> this. Does this mean these pages fail compliance (especially if mandated)?
> Additionally, if a page has validation errors, would this be an
> accessibility compliance concern?
>
> --
> Dennis Deacon
> Email: = EMAIL ADDRESS REMOVED =
> Website/Portfolio: dennisdeacon.com
> Blog: dennisdeacon.com/blog
> LinkedIn Profile: linkedin.com/in/dennisdeacon
> > > > >

From: Alastair Campbell
Date: Thu, Feb 25 2016 5:11AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | Next message →

Wow, it's been a while since I thought about XHTML!

WCAG 2 (4.1.1) doesn't require validation, but does say that "elements are
nested according to their specifications", so unless you switch doctype I
think it would be a technical fail.

In this case (and anyone please jump in to correct me), I don't think
browsers will actually interpret it any differently from HTML5.

From what I remember, HTML4.1, XHTML trans and HTML5 will all use the same
rendering modes. If you use XHTML strict and worry about IE previous to 8,
there can be some oddities in different modes, but you would probably have
spotted those already.

Have you tested just changing the doctype? Going XHTML to HTML5 is pretty
painless compared to the other way around.

My main accessibility concern would be the very verbose link-text that can
be created. We tend to use a small text link (e.g. the heading) and then a
little script to make the whole block click-able.

Cheers,

-Alastair



On Thu, Feb 25, 2016 at 11:55 AM, Dennis Deacon < = EMAIL ADDRESS REMOVED = >
wrote:

> We use block links throughout our website for advertisements, offers, etc.
> I've recently learned that block links are officially only supported
> starting with HTML5. So while the web browser handles them fine
> (seemingly), and only irritate screen reader users (unfortunately), this
> technically fails validation. How does this relate to the "R" in WCAG's
> POUR principles (Robust)?
>
> I see mention that under parsing, web pages should validate, with the HTML
> conforming to specifications. Block links under a XHTML doctype would fail
> this. Does this mean these pages fail compliance (especially if mandated)?
> Additionally, if a page has validation errors, would this be an
> accessibility compliance concern?
>
>

From: Steve Faulkner
Date: Thu, Feb 25 2016 5:16AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | Next message →

On 25 February 2016 at 12:11, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:

> My main accessibility concern would be the very verbose link-text that can
> be created.
>

yeah, same here
https://www.paciellogroup.com/blog/2011/06/html5-accessibility-chops-block-links/

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Patrick H. Lauke
Date: Thu, Feb 25 2016 5:17AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | Next message →

On 25/02/2016 11:55, Dennis Deacon wrote:
> We use block links throughout our website for advertisements, offers, etc.
> I've recently learned that block links are officially only supported
> starting with HTML5. So while the web browser handles them fine
> (seemingly), and only irritate screen reader users (unfortunately), this
> technically fails validation. How does this relate to the "R" in WCAG's
> POUR principles (Robust)?
>
> I see mention that under parsing, web pages should validate, with the HTML
> conforming to specifications. Block links under a XHTML doctype would fail
> this. Does this mean these pages fail compliance (especially if mandated)?
> Additionally, if a page has validation errors, would this be an
> accessibility compliance concern?

Note that validation is not mandated, but simply a sufficient technique
for 4.1.1 - meaning that even if a markup validator throws up errors,
that does not necessarily mean that it's a FAIL of 4.1.1.

The main concern of 4.1.1 is to ensure that user agents consistently
interpret the markup and generate the same DOM structure from it. As
most modern browsers interpret broken markup the same(ish) way (as the
markup parsing algorithm has been more thoroughly defined in HTML5 and
implemented in browsers), the chance of broken markup messing up in
specific user agents (and then leading to accessibility problems) is
lower nowadays. Nonetheless, the main things that should still be
avoided (even though these should still actually result in the same DOM)
are mainly making sure you have correct opening/closing tags, you don't
misnest things (like <p><strong>...</p></strong> or similar), don't have
duplicate ID attributes, don't have duplicate attributes with
conflicting values.

But, picking up from Steve's comment: why are you using and XHTML
doctype? Simply replacing that with the minimal HTML5 doctype of
<!DOCTYPE html> should not have any effect on how your content is
actually interpreted/displayed in browsers, and will have the added
benefit of automatically running validation against the more modern spec
(meaning fewer errors will be flagged up).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Dennis Deacon
Date: Thu, Feb 25 2016 6:24AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | Next message →

All, thanks for the chuckle during the morning commute. Need that. :-)

The site is a large eCommerce site, 15% on a new HTML5 platform, the
remaining on an older XHTML 1.0 Transitional platform, which won't be
migrated within the next year or so to the newer platform.

With that said, I'm aware that changing the doctype to HTML5 is easy and a
no-brainer. The issue will be motivating the senior leadership to dictate
the change to .NET masterpages to IT, thereby creating fear of things
breaking throughout the 1800+ pages on the older doctype. My inquiry was to
plan for "what if we don't change doctypes." We have a mandated deadline
and I've trying to stave off as many fire drills as possible (while noble,
in reality, futile).

I attempted to perform a quick test in the browser dev tool, but see I
can't edit the doctype in Web Inspector, Firebug, etc. Any other method for
changing doctype for a page load in-browser? Our group does not have access
to the masterpages, even in the dev environment.

Thanks again for all your comments and advice.

--
Dennis Deacon
Email: = EMAIL ADDRESS REMOVED =
Website/Portfolio: dennisdeacon.com
Blog: dennisdeacon.com/blog
LinkedIn Profile: linkedin.com/in/dennisdeacon

From: Alastair Campbell
Date: Thu, Feb 25 2016 7:07AM
Subject: Re: Block Links & Other Validation Issues in XHTML 1.0 Transitional
← Previous message | No next message

Dennis Deacon wrote:

> I attempted to perform a quick test in the browser dev tool, but see I
> can't edit the doctype in Web Inspector, Firebug, etc.
>

You could save the HTML from a page locally and use <base href="
http://example.com/">

Although I'm not sure how well that works anymore, last time I tried
Firefox wouldn't load external sources, so perhaps that method is dead?

-Alastair