Re: [HTMLWG] CfC: Adopt "Plan 2014" and make some specific related decisions

Hi Henri,

In practice, it would mean two implementors working on two distinct
> browser engines saying that the proposed feature is a good idea that
> they would like to implement and realistically might.
>

Ok so have talked to the main chrome accessibility engineer, and he
indicated that he would implement it if it had support from the community.


regards
SteveF

On 15 October 2012 15:22, Henri Sivonen <hsivonen@iki.fi> wrote:

> On Fri, Oct 12, 2012 at 4:45 PM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
> > What does "broader buy-in, including from implementors, showing that the
> > extension specification is seen as a good idea." mean in practice?
>
> In practice, it would mean two implementors working on two distinct
> browser engines saying that the proposed feature is a good idea that
> they would like to implement and realistically might. (No
> authoritative commitment to implement or a statement about timeline
> required.) Ideally, it would also mean an indication of support and
> likelihood of adoption from Web authors, but, as far as I can tell,
> the W3C or its participants have not yet figured out how to
> meaningfully gauge if Web authors would actually like to use a feature
> if the feature existed. (You can probably always find a couple of Web
> authors who say they like a given feature, but that doesn't really
> tell you anything about what kind of author adoption a feature would
> really get on the Web scale.)
>
> > What we know from the hgroup feature is that it does not have buy-in from
> > vendors for the implementation aspects that have any real effect (outline
> > and accessibility API mapping). We know that it does no have wide support
> > from the various communities. we know various proposals for
> > removal/replacement were submitted form varying sources. i.e its not
> seen as
> > being a good idea and that has been the case for an extended period of
> time.
>
> I was talking about the standard of inclusion for new features. At
> this point, hgroup in the parser or UA stylesheet is not a prospective
> new idea but an interoperably implemented piece of the Web Platform.
>
> If you combine my position on hgroup in the parser and UA stylesheet
> and your outlook for it affecting the outline exposed for
> accessibility, it would not be unreasonable to conclude that the
> standard of inclusion at the WHATWG has been too lax in the case of
> hgroup. However, there is no logical contradiction between my position
> on keeping hgroup in the parser and the UA stylesheet and at the same
> time calling for a stricter standard of inclusion for future features.
>
> As for support in the various communities, I think it's semi-relevant
> to mention that what constitutes a valid an EPUB3 Navigation Document
> involves a normative statement about hgroup. This is not necessarily
> an endorsement of hgroup by the IDPF, since the normative statement is
> likely simply a result of working with what I draft of HTML5 provided.
> Also, I don't think the evolution of the Web Platform should be
> constrained by non-Web reuses of Web technology. My point is that at
> this point, there exists at least one external community that has
> already built upon the assumption that hgroup exists. (Their building
> upon it seems to be restricted to document conformance, though. I see
> no requirements on Reading Systems hinging on hgroup processing.)
>
> For Web authors to make pages for which the outline algorithm provides
> sensible outlines, I think it needs to have a tangible visual effect
> in Web authoring. I think in practice, that would mean having a
> selector that matches on the outline depth. I think implementing such
> a selector in a performant way would be the real test of
> implementability and merit for the outline algorithm in general and
> the role of hgroup in it in particular.
>
> > Taking another example, the <maincontent> element [3] this is an
> extension
> > specification that I will be putting forward as a FPWD, it builds on
> common
> > authoring practices it provides built in rather than bolt on
> accessibility,
> > it has support from the developer and accessibility community, in
> > discussions I have had with accessibility engineers from mozilla they
> > indicated that they would implement the accessibility mapping, it is
> > publically available for wider review, no implementors have objected to
> it
> > (yet), what more do I need to do for it be considered as reasonable for
> > publishing as a FPWD?
>
> Another implementor expressing an opinion that it is a good idea and
> interest in implementing the accessibility mapping in a non-Gecko
> engine.
>
> --
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
>
>


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html