Re: ARIA Extensions Definitional Statement

Well - I certainly regret not attending the meeting today.  I don't begin
to comprehend why it would be a good idea to have a Rec-Track document that
defined ARIA "extensions" that were all optional.  The whole reason that
draft process was written the way it was written was to say that if a
document is an extension and becomes a Recommendation then it's
non-optional components are required of all implementations.

If a user cannot count upon that, then absent an announcement mechanism
(which HTML has eschewed and I am personally NOT willing to have that fight
again) there is no way a user is going to try to use the bits of that
extension.   "What if you held a party and nobody came?"  I must be missing
something here.

I agree that there is an open question about *when* support of non-optional
portions would become required for conformance.  That's why I put in the
phrase about hand waving.  I assumed that ultimately we would come to some
agreement like "Any ARIA extension specifications that have reached
Recommendation status at the time the ARIA Core is revised and approved as
a superseding Recommendation will be considered to be a part of ARIA Core
and their non-optional components required of all ARIA conforming
implementations."  Oh well.  I guess the user agent implementors win, and
differently-abled end users lose.  Again.



On Wed, May 20, 2015 at 4:55 PM, Janina Sajka <janina@rednote.net> wrote:

> Shane McCarron writes:
> > Sorry I missed the discussion.  Optional modules?  Huh.
>
> Indeed, stay tuned! <grin>
>
> The question remains what, among the growing corpus of ARIA modules,
> does a general purpose user agent like IE, Firefox, or Chrome, need to
> implement to legitimately claim conformance to ARIA X.Y. Are they all
> expected to do D-Pub and SVG? What if some enterprising university
> writes up Molecular Biology using ARIA-SVG constructs? Would Firefox
> need to directly support that?
>
> We benefit if we can support a Molecular-Biology-ARIA module, but we'd
> never get it were we to require direct support in all conforming user
> agents.
>
> So, we need a demarcation specified somehow--one which supports those
> user agents who care (think of plugins, extensions to Firefox, etc) able
> to say: "I implement X-ARIA" without the host browser needing to support
> X-ARIA directly.
>
> >
> > On Wed, May 20, 2015 at 1:58 PM, Janina Sajka <janina@rednote.net>
> wrote:
> >
> > > A further thought to today's PF discussion on the ARIA Extension
> > > statement ..:
> > >
> > > https://www.w3.org/WAI/PF/wiki/ARIAExtensions
> > >
> > > May I suggest we tweak the top statement about HTML's extension
> > > specification to say:
> > >
> > > "Note: This model is based upon, but diverges from the HTML Working
> > > Group's model for Extension specifications."
> > >
> > > As we discussed today, we're steering toward optional modules, and HTML
> > > extensions are not optional.
> > >
> > > Janina
> > >
> > > --
> > >
> > > Janina Sajka,   Phone:  +1.443.300.2200
> > >                         sip:janina@asterisk.rednote.net
> > >                 Email:  janina@rednote.net
> > >
> > > Linux Foundation Fellow
> > > Executive Chair, Accessibility Workgroup:       http://a11y.org
> > >
> > > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> > > Chair,  Protocols & Formats     http://www.w3.org/wai/pf
> > >
> > >
> >
> >
> > --
> > Shane McCarron
> > Managing Director, Applied Testing and Technology, Inc.
>
> --
>
> Janina Sajka,   Phone:  +1.443.300.2200
>                         sip:janina@asterisk.rednote.net
>                 Email:  janina@rednote.net
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:       http://a11y.org
>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,  Protocols & Formats     http://www.w3.org/wai/pf
>
>


-- 
Shane McCarron
Managing Director, Applied Testing and Technology, Inc.