W3C home > Mailing lists > Public > public-digipub-ig@w3.org > July 2014

Re: Please Support the Proposed W3C Web Annotations WG Charter

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Fri, 18 Jul 2014 17:23:50 -0500
To: Doug Schepers <schepers@w3.org>
Cc: public-digipub-ig@w3.org, "W3C WAI Protocols & Formats" <public-pfwg@w3.org>
Message-ID: <OF0CC73BBF.39FD5B81-ON86257D17.005DC9BC-86257D19.007B07C1@us.ibm.com>



Rich Schwerdtfeger

Doug Schepers <schepers@w3.org> wrote on 07/16/2014 11:33:55 AM:

> From: Doug Schepers <schepers@w3.org>
> To: Richard Schwerdtfeger/Austin/IBM@IBMUS
> Cc: public-digipub-ig@w3.org
> Date: 07/16/2014 11:34 AM
> Subject: Re: Please Support the Proposed W3C Web Annotations WG Charter
>
> Hi, Rich–
>
> Thanks for the update. I knew about the requirement from the Microsoft
> guys who attended the workshop. It's good to know that that use case
> will be covered; for those that control (e.g. have write control) of the
> target document, it's important to have a standard way to indicate that
> there is an annotation available (similar to "described-at", really...
> "annotated-at") so that readers can identify and navigate from and back
> to tag-marked selections (e.g., discovering that a passage marked up
> with a <span> has annotations available for it, actively navigating to
> those annotations, reading them, then navigating back to the original
> context).
>


> There is another use case that's equally important, and will perhaps be
> even more common: the case where the annotation is on a document where
> the annotator doesn't have write access, and the annotation is stored on
> another server, along with selectors for identifying the target passage,
> and is dynamically reanchored on demand (the distributed, Open
> Annotation model).
>
> For some implementations, this could even be the same solution: the
> annotation engine finds the selections, and inserts <span
> class="annotation" aria-annotated-at="http://example.com/user123/foo">
> or <span class="annotation" aria-annotated-at="#user123_foo"> around the
> selection; that annotation is styled appropriately for sighted users as
> well. This is doable, but may be more of a brute-force approach, and has
> security and privacy issues; it also has challenges around overlapping
> element boundaries, especially elements that are themselves annotations
> (e.g. 20 people all leave annotations on the same couple of paragraphs,
> with different overlapping start and end points); it's muddled even
> further if it's a dynamic document that's being actively edited, with
> both text and element content changing, being added and removed. I
> suspect this approach won't scale terribly well for many cases, but it
> has the advantage that you can (mostly) do it today; the ARIA and
> accessibility API hooks are still pending.
>
OK. So, like the aria-describedat but for annotations.


> For other implementations, we have in mind another solution: the
> annotation engine finds the selections, via a (hypothetical)
> find-in-page API that returns a list of ranges; these ranges are
> assigned "names" via a (hypothetical) method that instantiates them as
> CSS pseudo-elements. Because there are no DOM mutations, these
> pseudo-element ranges can overlap without any problems to either the
> annotation markers or other DOM elements, can be dynamically styled, and
> can be plugged into an accessibility API for discovery and navigation
> (albeit not using the ARIA mechanism); they can be styled in a way that
> does not cause performance problems (using a limited set of properties
> that do not affect document reflow) and is opaque to page scripts (as
> with :visited links) to decrease the privacy and security implications.
> This would scale better, and would tie in nicely with other needs of the
> Web Platform, such as a more refined find-in-page API and a
> selection/range-styling mechanism (both of which are useful for advanced
> WYSIWYG in-browser editing capabilities), but it has the disadvantage
> that it needs implementation in browsers, so it's longer-term.
>
> I think both these approaches can live in harmony. In both cases, we'll
> need the same accessibility API hooks, the same UI and UX
> considerations, and the same high-level conceptual framework. So let's
> keep working toward that mutual goal.
>
> And here's where I put in another shameless plug for all of you to get
> your AC rep to approve the Web Annotations WG charter [1], today, so we
> can get to work! :D
>

ok. I am copying this to the public pfwg list.

Thanks,
rich

> [1] https://www.w3.org/2002/09/wbs/33280/annowg/

>
> Regards-
> -Doug
>
> On 7/16/14 11:23 AM, Richard Schwerdtfeger wrote:
> > Doug, you should know that ARIA 1.1 is adding annotations semantics to
> > web pages to produce accessible annotations. This came out of
> > requirements from the MS Office team working on Office cloud offerings.
> >
> > Cheers,
> > Rich
> >
> >
> > Rich Schwerdtfeger
> >
> > Inactive hide details for Doug Schepers ---07/15/2014 11:55:09 AM---Hi,
> > Digital Publication IG– I'm writing you directly to asDoug Schepers
> > ---07/15/2014 11:55:09 AM---Hi, Digital Publication IG– I'm writing you
> > directly to ask you to support the formation of the prop
> >
> > From: Doug Schepers <schepers@w3.org>
> > To: public-digipub-ig@w3.org
> > Date: 07/15/2014 11:55 AM
> > Subject: Please Support the Proposed W3C Web Annotations WG Charter
> >
> >
------------------------------------------------------------------------
> >
> >
> >
> > Hi, Digital Publication IG–
> >
> > I'm writing you directly to ask you to support the formation of the
> > proposed Web Annotation Working Group. The charter is currently under
> > Advisory Committee review.
> >
> > I know that annotations are of general interest to this group, so I
> > don't need to tell you how important this is. If you want to see this
> > work move forward, it's important that you indicate your support to
help
> > W3C management set priorities.
> >
> > If you're a W3C Member, to register your interest, simply fill out the
> > AC review form for the Web Annotations WG charter [1]. If you are
> > passionate about W3C standardizing annotations, you can also fill out
> > the AC review form for the WebApps WG charter [2], and explicitly
> > mention the Robust Anchoring deliverable that is a joint deliverable
> > between the WebApps and Web Annotations WGs.
> >
> > Filling out both forms should only take about 5-10 minutes, and the AC
> > review for the WebApps WG charter ends on Thursday, so please take some
> > time now to fill out these forms. We really appreciate it.
> >
> > If you're not a W3C Member, nothing shows your support for Web
> > annotations more than joining W3C now. :) But if you can't join W3C,
you
> > can still help by spreading the word.
> >
> > For background, back in April 2014, W3C held a Web Annotations
Workshop;
> > in the workshop report [3], you can read the presentation and
discussion
> > summaries, and watch the videos of the event.
> >
> > Some of the highlights were the importance of importance of
standardized
> > annotations for accessibility [4], for education, and for digital
> > publishing.
> >
> > If you'd like to hear more about Web annotations, and how it might help
> > your organization, please feel free to contact me, and I'd be happy to
> > talk to you.
> >
> > [1] https://www.w3.org/2002/09/wbs/33280/annowg/

> > [2] https://www.w3.org/2002/09/wbs/33280/webapps-2014/

> > [3] http://www.w3.org/2014/04/annotation/report.html

> > [4] http://www.w3.org/2014/04/annotation/slides/gerardo-slides.pdf

> >
> > Regards–
> > –Doug Schepers (W3C)
> >
> >
> >
>
>
>
Received on Friday, 18 July 2014 22:24:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:35:51 UTC