E-mail List Archives
Thread: Frames differ by browser
Number of posts in this thread: 12 (In chronological order)
From: Sharon M Trerise
Date: Tue, Jan 10 2017 9:05AM
Subject: Frames differ by browser
No previous message | Next message →
Can someone help me understand why the frame names appear to be different for different browsers? I'm looking at DegreeWorks and when I list the frames in JAWS (Insert F9) I get 3 different lists depending on which browser I am using: IE, Firefox or Chrome. I believe I am listing the frames from the same entry point in each browser.
Thanks.
Sharon
Sharon Trerise | IT Analyst - Accessibility
Information Technology Services
1-205 CST
Syracuse University
Syracuse, New York 13244
t 315.443.2143 e = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > w its.syr.edu<http://its.syr.edu>;
SYRACUSE UNIVERSITY
syr.edu<http://syr.edu>;
From: Birkir R. Gunnarsson
Date: Tue, Jan 10 2017 9:24AM
Subject: Re: Frames differ by browser
← Previous message | Next message →
There is some confusion as to whether the frame title comes from the
<title> element inside the frame, or the title attribute on the frame
element.
e.g.
<iframe title="ghosts">
<head>
<title>busters</title>
<head>
<body>
stuff about ghost busters, who you gonna call?
</body>
</iframe>
I don't remember the specifics. I think IE/Jaws always goes with the
<title> element inside the frame, ignoring the title attribute.
On 1/10/17, Sharon M Trerise < = EMAIL ADDRESS REMOVED = > wrote:
> Can someone help me understand why the frame names appear to be different
> for different browsers? I'm looking at DegreeWorks and when I list the
> frames in JAWS (Insert F9) I get 3 different lists depending on which
> browser I am using: IE, Firefox or Chrome. I believe I am listing the
> frames from the same entry point in each browser.
>
> Thanks.
>
> Sharon
>
> Sharon Trerise | IT Analyst - Accessibility
> Information Technology Services
> 1-205 CST
> Syracuse University
> Syracuse, New York 13244
> t 315.443.2143 e = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > w
> its.syr.edu<http://its.syr.edu>;
> SYRACUSE UNIVERSITY
> syr.edu<http://syr.edu>;
>
> > > > >
--
Work hard. Have fun. Make history.
From: JP Jamous
Date: Tue, Jan 10 2017 9:42AM
Subject: Re: Frames differ by browser
← Previous message | Next message →
You are correct. I dealt with it not too long ago. I still remember.
From: JP Jamous
Date: Tue, Jan 10 2017 9:44AM
Subject: Re: Frames differ by browser
← Previous message | Next message →
Sharon,
Try to remove the page title inside the frame.
<Title></title>
Use the iframe title to set what you want it to state. That should work with JAWS and Internet Explorer.
From: Beranek, Nicholas
Date: Tue, Jan 10 2017 11:15AM
Subject: Re: Frames differ by browser
← Previous message | Next message →
What if you don't have direct control over the contents of the <iframe>? I think it's prudent to maintain both the <title> of the framed content as well as the title attribute on the <iframe>. Thoughts?
As for the discrepancies between each browser, it's a possibility that they're calculating the accessible name for the frame differently. Have you ever used the MSAA Object Inspect tool to verify what is being calculated by the accessibility API?
Nick
From: JP Jamous
Date: Tue, Jan 10 2017 11:28AM
Subject: Re: Frames differ by browser
← Previous message | Next message →
1. I assumed that she has control over the page inside the frame. If not, then the only solution I have been able to come up with was aria-label rather than the Iframe title. I don't like it, but thanks to the SR manufacturers, it solves the issue.
2. I have not had the chance to mess with the MSAA viewer. That is one of the things on my list. Is it accessible with JAWS?
From: Beranek, Nicholas
Date: Tue, Jan 10 2017 1:08PM
Subject: Re: Frames differ by browser
← Previous message | Next message →
It's a little tricky to find as it's embedded within the Windows SDK as Inspect32.exe. If you can find it, then it is a very powerful tool. I have done some basic testing with JAWS and it appears to be a simple Tree View with adjacent panel containing the accessibility information for the focused element.
You could try aViewer instead as it presents you the same information and is readily available:
https://www.paciellogroup.com/resources/aviewer/
Nick
From: JP Jamous
Date: Tue, Jan 10 2017 2:43PM
Subject: Re: Frames differ by browser
← Previous message | Next message →
Thank you Nick. That is very helpful.
From: Birkir R. Gunnarsson
Date: Tue, Jan 10 2017 2:50PM
Subject: Re: Frames differ by browser
← Previous message | Next message →
The WCAG 2.4.1 text and techniques all refer to using the title
element on the frame.
FAct is that, according to the accessible name calculation native HTML
labeling comes before title (in this case I guess it would be the
<title> element inside the frame).
I agree, use aria-label to be safe (it beats out the native HTmL
labeling and you usually have control over it).
If the title still doesn't come through, you can place the frame in a
<div> with role="region" and aria-label="whatever the title should
be".
That way you have provided the label or the frame, albeit in a roundabout way.
On 1/10/17, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you Nick. That is very helpful.
>
>
From: Rakesh P
Date: Tue, Jan 10 2017 6:18PM
Subject: Re: Frames differ by browser
← Previous message | Next message →
That's an interesting observation and great solutions to resolve. Another
common problem I observed with iFrames when used <title></title> is the
language attribute. Considering iFrames as a separate page within the
parent page automation tools throw 3.1.1 Missing language attribute . I
really doubt how can the developers fix this when the iFrame content is
controlled by third party.
On Wed, Jan 11, 2017 at 3:20 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> The WCAG 2.4.1 text and techniques all refer to using the title
> element on the frame.
> FAct is that, according to the accessible name calculation native HTML
> labeling comes before title (in this case I guess it would be the
> <title> element inside the frame).
> I agree, use aria-label to be safe (it beats out the native HTmL
> labeling and you usually have control over it).
> If the title still doesn't come through, you can place the frame in a
> <div> with role="region" and aria-label="whatever the title should
> be".
> That way you have provided the label or the frame, albeit in a roundabout
> way.
>
>
> On 1/10/17, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> > Thank you Nick. That is very helpful.
> >
> >
From: Beranek, Nicholas
Date: Tue, Jan 10 2017 10:27PM
Subject: Re: Frames differ by browser
← Previous message | Next message →
The framed content should inherit the language of the parent page. Partial conformance can be claimed since the content is served by a third party. See the following link for more details:
https://www.w3.org/TR/WCAG20/#conformance-partial
Nick
Sent with Good (www.good.com)
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Rakesh P < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, January 10, 2017 8:18:20 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Frames differ by browser
That's an interesting observation and great solutions to resolve. Another
common problem I observed with iFrames when used <title></title> is the
language attribute. Considering iFrames as a separate page within the
parent page automation tools throw 3.1.1 Missing language attribute . I
really doubt how can the developers fix this when the iFrame content is
controlled by third party.
On Wed, Jan 11, 2017 at 3:20 AM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:
> The WCAG 2.4.1 text and techniques all refer to using the title
> element on the frame.
> FAct is that, according to the accessible name calculation native HTML
> labeling comes before title (in this case I guess it would be the
> <title> element inside the frame).
> I agree, use aria-label to be safe (it beats out the native HTmL
> labeling and you usually have control over it).
> If the title still doesn't come through, you can place the frame in a
> <div> with role="region" and aria-label="whatever the title should
> be".
> That way you have provided the label or the frame, albeit in a roundabout
> way.
>
>
> On 1/10/17, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> > Thank you Nick. That is very helpful.
> >
> >
From: Jonathan Avila
Date: Wed, Jan 11 2017 8:30AM
Subject: Re: Frames differ by browser
← Previous message | No next message
> Fact is that, according to the accessible name calculation native HTML labeling comes before title (in this case I guess it would be the <title> element inside the frame).
For the purposes of the iFrame -- it is my understanding the title element of the content document is not taken into account.
According to the HTML Accessibility API Mappings 1.0
https://www.w3.org/TR/html-aam-1.0/
5.13.1 iframe Element Accessible Name Computation
If the element has an aria-label or an aria-labelledby attribute the accessible name is to be calculated using the algorithm defined in Accessible Name and Description: Computation and API Mappings 1.1.
Otherwise use the title attribute
If none of the above yield a usable text string there is no accessible name
NOTE
The document referenced by the src of the iframe element gets its name from that document's title element, like any other document. If there is no title provided, there is no accessible name.
Jonathan
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)
Vis Visit us online: Website | Twitter | Facebook | LinkedIn | Blog
See you at CSUN in March!
The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.