Re: WCAG 2.0 4.1.1 Parsing (elements have complete start and end tags)

This is always the way that I have interpreted it. As you suggest adding
this rationale/explanation/clarification.  in the Understanding Doc and the
associated 4.1.1 Techniques is a good idea.

* katie *

Katie Haritos-Shea @ GMAIL
On Feb 9, 2014 3:53 PM, "Gregg Vanderheiden" <gv@trace.wisc.edu> wrote:

> I believe the way to do this is to explain -- in the Understanding
> document --   that
>
>  "*Complete start and end tags*"  does not mean "*matching start and end
> tags*".  They key is always what is in the specification.  If a
> specification only requires one tag in some cases then one tag would
> constitute "complete start and end tags" for that feature.     The phrasing
> of the success criterion was chosen to differentiate situations where
> specifications *require* start and end tags, but they are often missing
> because browsers can repair and recover from missing tags, but
> unfortunately not all AT could.   The language in the success criterion was
> never intended, and should not be interpreted to mean, that WCAG requires
> start or end tags that are not *required * by the specification."
>
>
> gregg
>
>
>
> On Feb 9, 2014, at 10:15 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
> wrote:
>
> I agree with James's interpretation also.  This language is not open for
> changes at this time but we can make sure that the understanding document
> helps make this clear.  If you have any suggestions for increasing the
> clarity, please pass them on..
>
> *From:* Steve Faulkner [mailto:faulkner.steve@gmail.com<faulkner.steve@gmail.com>
> ]
> *Sent:* Sunday, February 09, 2014 10:20 AM
> *To:* James Nurthen
> *Cc:* w3c-wai-gl@w3.org; HTMLWG WG; HTML Accessibility Task Force;
> Richard Schwerdtfeger
> *Subject:* Re: WCAG 2.0 4.1.1 Parsing (elements have complete start and
> end tags)
>
>
>
> "4.1.1 Parsing: In content implemented using markup languages, elements
> have complete start and end tags, elements are nested according to their
> specifications, elements do not contain duplicate attributes, and any IDs
> are unique, except where the specifications allow these features. "
>
>
>
> thanks James, that makes sense. though the wording could be clearer, while
> I have always considered optional end tags to be OK others have interpreted
> wcag as requiring them.
>
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>
>
> On 9 February 2014 15:10, James Nurthen <james.nurthen@oracle.com> wrote:
> Steve,
> The complete text is
> "4.1.1 Parsing: In content implemented using markup languages, elements
> have complete start and end tags, elements are nested according to their
> specifications, elements do not contain duplicate attributes, and any IDs
> are unique, except where the specifications allow these features. "
>
> As you have stated, the html specification allows certain end tags to be
> optional and some have no end tags so there is no issue with 4.1.1 as the
> specification allows these features.
>
> Regards,
> James
>
>
>
> On Feb 9, 2014, at 5:58 AM, Steve Faulkner <faulkner.steve@gmail.com>
> wrote:
>
> > criteria 4.1.1 [1] parsing, requires complete start and end tags for all
> elements.
> >
> > "In content implemented using markup languages, elements have complete
> start and end tags"
> >
> > in HTML end tags certain end tags are optional [2] and certain elements
> have no end tags (<img>, <input> etc.) How do we explain/reconcile this
> disparity?
> >
> >
> >
> > [1] http://www.w3.org/TR/WCAG20/#ensure-compat
> >
> > [2]
> http://www.w3.org/html/wg/drafts/html/master/syntax.html#syntax-tag-omission
> :
> > --
> >
> > Regards
> >
> > SteveF
> > HTML 5.1
>
>
>