RE: Another run at grappling with @poster

Silvia Pfeiffer wrote:
> 
> John, I personally think that the 4 issues that you are mentioning for
> aria-describedby can be addressed and I agree that the use of
> aria-describedby will indeed satisfy our use cases.

Silvia,

I agree that using aria-describedby _can_ be an elegant solution, but for
it to work we need the user-agents - the browsers - on board. It is the
user-agents - the tool that passes the required data on through to the
Accessibility APIs, that need to do some heavy lifting to make this work.
Screen Readers and related AT can only process what is passed to them from
the browsers.

> 
> I'll make some notes inline on these.
> 
> The key issue, though, is that it would be really helpful if
> aria-describedby could be clarified in the ARIA CR

I am concerned that we may be too late - Candidate Recommendations at the
W3C are generally locked down pretty tight. However both HTML 4 (4.01
actually) and XHTML 1 (1.1 actually) had rapid addendums/point changes
added in the life-cycles, so there may be a possibility to do something,
but timing is and will remain an issue.

> that the markup in
> the HTML fragments that aria-describedby points to are retained and
> need to be exposed by screen readers and AT,

Point of clarification: exposed *to* screen readers and AT, not by those
tools.


> in particular links to
> other resources, language markup, and paragraph markup that will
> introduces pauses and navigation means.

Yes, and this too is an important point to remember - currently the
flattening of aria-describedby text also removes support for
multi-language support: <span lang="fr">croissant</span> will still be
announced croysant.

> 
> 
> I believe after today's discussion that the pausing problem can be
> addressed if the HTML fragments that aria-describedby links to retain
> their markup. For example, if they are in different <p> elements, then
> a pause would automatically happen and navigation between different
> pieces of information would be possible. If no such markup is there, I
> would expect the same kind of pauses be made as they are when
> sentences are finished.

+1

> 
> 
> > 2) I have a concern that apparently HTML-rich text being passed to
> the
> > Accessibility API is being "flattened" - i.e. none of the HTML-
> richness is
> > preserved. This would thus kill off the link being provided by: "A
> full
> > description of the poster is also available." (This has surfaced in
> the
> > @longdesc discussion as well: apparently Firefox is preserving the
> > richness - needs to be tested/confirmed - but the other browsers are
> not.
> > This might be a deal-breaker here.)
> 
> 
> I agree - aria-describedby needs to retain the linked elements'
> internal structure when handing it on to AT for this to work. This may
> need clarification in the ARIA CR.

Once again I am concerned that ARIA CR is pretty far along. However we
were extremely fortunate to have 3/4 of the editorial team of UAAG 2 on
our call today, and UAAG 2 is still a Working Draft. This begs the
question to Jim, Kelly and Jeanne - is describing/prescribing User Agent
processing rules (such as here) in scope for UAAG, and can we get good
language there that we can then point to when filing bugs at the browser
vendors? I ask because this was a point made by Eric last week - we need
something definitive to point the engineers too when filing a bug. (As an
aside, I believe that this problem, and possible solution, is actually
larger than the issue being discussed here - clearly it directly impacts
our discussion, but it has impact on other work efforts as well.)


> 
> 
> > 3) Order of reading: 
> >
> > Is this a problem (I can see where it might be sometimes)? Is this
> > addressed exclusively as authoring guidance, or is there a way we can
> > specify rendering order regardless of authoring order? Is this worth
> > worrying about?
> 
> I would think that the order is retained

I think so too, but am looking to Rich or the UAAG folks to confirm or
deny that this is either expected or even defined behavior - and if not
defined, should it be?

> and therefore it is up to the
> author to choose the order and make it such that it results in the
> best experience for the user.

Which means good authoring guidance (WCAG) as well. We have started to
identify these types of author-guidance requirements elsewhere as well,
and are compiling them.


> This may also need clarification in the
> ARIA CR.

See previous comments re: re-opening ARIA.

JF

Received on Thursday, 23 June 2011 14:20:17 UTC