Re: accessible footnotes and the aria-flowto attribute

Switching to the public list.

@aria-flowto doesn't buy us much here over a standard link. 

Why not just use rel=footnote as defined in HTML4? I think I would oppose a new @aria-footnote attribute, but I believe role=footnote would be okay on the target of the link that specified rel=footnote. 


> On Jan 3, 2015, at 7:20 AM, George Kerscher <kerscher@montana.com> wrote:
> 
> Hi,
>  
> Ibooks, Readium, and other reading systems use footnotes extensively. Using the aria-footnote attribute proposed by  the DPUB interest group

If you have the link to the proposal, its good to keep that inline with the discussion. 

> will correctly identify the semantics of the element. There are several behaviors that reading systems have evolved to address the wanted behavior.
>  
> Best
> George
>  
> From: Birkir Gunnarsson [mailto:birkir.gunnarsson@deque.com] 
> Sent: Saturday, January 03, 2015 4:34 AM
> To: w3c-wai-pf@w3.org
> Subject: accessible footnotes and the aria-flowto attribute
>  
>> Happy new year to thee lords and ladies.
>>  
>> I have a quick question on the aria-flowto attribute and making footnote navigation accessible in html.
>> I know we have proposed ways to make footnotes more accessible, which is a good thing.
>> But we already have a pretty useful attribute for this, namely aria-flowto.
>> The only combination of screen reader and browser that supports this is Jaws with FF (tested with 33).
>> Putting the id of the alternative reading order (the footnote) on the associate element causes Jaws to announce “flows available) as you navigate to the element with a footnote.
>> Pressing “=” takes user to the element.
>> Pressing shift-= will take user back from the footnote to the triggering element.
>> Even when you have more than one elements associated with a single footnote, Jaws offers a list of matches, and if there is an accessible name available (using aria-label on a div actually worked), user can select from a pop-up list.
>> So my question is basically, was this element abandoned or are we just facing a case of screen reader vendors and browser manufacturers not putting this high in the pecking order of things to do (and this is not meant as a criticism, there is a lot that has to be done).
>> The thing is that the implementation described above was mentioned at CSUN 2011 so it has been around for awhile.
>> At least in HTML this looks easy and ideal to me, so the question is more of supporting an existing element than inventing new and more complex mechanisms to achieve the same purpose.
>> Thanks to anyone willing and able to shed some light on this situation.
>> -Birkir
>>  
>>  
>> Birkir Gunnarsson
>> Sr. Accessibility Consultant
>

Received on Monday, 5 January 2015 18:29:53 UTC