E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Isabel Holdsworth
Date: Thu, Jul 12 2018 6:49AM
Subject: Multiple documents in a single webpage
No previous message | Next message →

Hi all,

We have a webpage with a button that, when pressed, loads a document,
spreadsheet or image into a dialog that's positioned at the bottom of
the DOM. So we effectively have two items of content residing on the
same webpage.

Currently there's nothing to distinguish the new content from the
existing apart from an H1 heading and a div that looks visually like a
draggable non-modal dialog box.

I'd really appreciate your thoughts on the best way to structurally
present the new content so it's distinguishable as a separate entity
from what was already on the page.

Thanks as always, Lynn

From: glen walker
Date: Thu, Jul 12 2018 2:10PM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

You said the dialog visually looks like a draggable non-modal dialog. Is
it really draggable or can it be moved via the keyboard? Or is it really a
fixed location on the screen and you're just styling it to look like a
moveable dialog?

Is there a quick keyboard way to move the focus from the "regular" part of
the page to the dialog area? A landmark would help an AT user but browsers
have not surfaced landmark navigation to keyboard users yet so you'd need a
skiplink or shortcut key (that's discoverable).

Any time the page is updated with new info, you should notify the user.
That's often done with aria-live regions.

You'd also have to decide whether to move the focus. In general, moving
the focus after selecting a button is shied away from, but in your case, if
I were using a screen magnifier and could only see the button and a limited
region around it, I might not notice that somewhere else on the screen was
updated unless the focus was moved to it (causing my magnified viewport to
move to the newly focused area).



On Thu, Jul 12, 2018 at 6:49 AM, Isabel Holdsworth <
= EMAIL ADDRESS REMOVED = > wrote:

> Hi all,
>
> We have a webpage with a button that, when pressed, loads a document,
> spreadsheet or image into a dialog that's positioned at the bottom of
> the DOM. So we effectively have two items of content residing on the
> same webpage.
>
> Currently there's nothing to distinguish the new content from the
> existing apart from an H1 heading and a div that looks visually like a
> draggable non-modal dialog box.
>
> I'd really appreciate your thoughts on the best way to structurally
> present the new content so it's distinguishable as a separate entity
> from what was already on the page.
>
> Thanks as always, Lynn
> > > > >

From: Isabel Holdsworth
Date: Fri, Jul 13 2018 6:03AM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

Thanks Glen - lots of good food for thought here.

The dialog is draggable using the keyboard. When the whole dialog has
focus, as I think it does once the button to open it has been pressed,
drag handles appear and the dialog can be moved using the mouse or
arrow keys.

There's not a quick skip link to move to the dialog at the moment. We
move focus straight there as soon as it opens, and pressing Close or
Escape hides it again and moves focus back to the opener.

The dialog is at the end of the DOM, and I'm suggesting its title is
an H1 heading. I could suggest a skip link back to the main document,
but where in the document should it move the focus to? The opener
perhaps, Or the first H1?

Thanks again, and have a great weekend.

Lynn

On 12/07/2018, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> You said the dialog visually looks like a draggable non-modal dialog. Is
> it really draggable or can it be moved via the keyboard? Or is it really a
> fixed location on the screen and you're just styling it to look like a
> moveable dialog?
>
> Is there a quick keyboard way to move the focus from the "regular" part of
> the page to the dialog area? A landmark would help an AT user but browsers
> have not surfaced landmark navigation to keyboard users yet so you'd need a
> skiplink or shortcut key (that's discoverable).
>
> Any time the page is updated with new info, you should notify the user.
> That's often done with aria-live regions.
>
> You'd also have to decide whether to move the focus. In general, moving
> the focus after selecting a button is shied away from, but in your case, if
> I were using a screen magnifier and could only see the button and a limited
> region around it, I might not notice that somewhere else on the screen was
> updated unless the focus was moved to it (causing my magnified viewport to
> move to the newly focused area).
>
>
>
> On Thu, Jul 12, 2018 at 6:49 AM, Isabel Holdsworth <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> Hi all,
>>
>> We have a webpage with a button that, when pressed, loads a document,
>> spreadsheet or image into a dialog that's positioned at the bottom of
>> the DOM. So we effectively have two items of content residing on the
>> same webpage.
>>
>> Currently there's nothing to distinguish the new content from the
>> existing apart from an H1 heading and a div that looks visually like a
>> draggable non-modal dialog box.
>>
>> I'd really appreciate your thoughts on the best way to structurally
>> present the new content so it's distinguishable as a separate entity
>> from what was already on the page.
>>
>> Thanks as always, Lynn
>> >> >> >> >>
> > > > >

From: mhysnm1964
Date: Fri, Jul 13 2018 6:52AM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

I have one question. How does the screen reader user know where they are
when you move the document within the page? What is the purpose of moving
the document?

From: Isabel Holdsworth
Date: Fri, Jul 13 2018 7:17AM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

If we didn't move the focus, screenreader users would be unlikely to
know that some new content had appeared. And it may be difficult for
them to find. If they pressed the button to open the dialog, chances
are they're interested in what's in there, so why not position the
cursor so they can begin reading at the correct place?.

The focus should rarely be moved programatically, but I think this is
one of those times when it's acceptable and even advisable.

On 13/07/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> I have one question. How does the screen reader user know where they are
> when you move the document within the page? What is the purpose of moving
> the document?
>
>

From: glen walker
Date: Fri, Jul 13 2018 12:43PM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

I think what Sean was asking about was moving the dialog itself. Since the
dialog can be moved by dragging it or using the move handles (nice job
allowing that from the keyboard), how does the AT user know where the
dialog is now?

With powerpoint, which I think I mentioned in some other thread, the
location of the object is announced as you move it around. You're also
notified if the object moves over the top or underneath another object. Is
anything like that announced when you move your dialog? Is the dialog
truly "on top" of the page in the background, or does stuff reflow around
it as you move it around? If it's on top, when it first appears, does
anything in the background get covered up? I'm guessing as you move it,
other stuff on the main page might get covered up?


On Fri, Jul 13, 2018 at 7:17 AM, Isabel Holdsworth <
= EMAIL ADDRESS REMOVED = > wrote:

> If we didn't move the focus, screenreader users would be unlikely to
> know that some new content had appeared. And it may be difficult for
> them to find. If they pressed the button to open the dialog, chances
> are they're interested in what's in there, so why not position the
> cursor so they can begin reading at the correct place?.
>
> The focus should rarely be moved programatically, but I think this is
> one of those times when it's acceptable and even advisable.
>
> On 13/07/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
> > I have one question. How does the screen reader user know where they are
> > when you move the document within the page? What is the purpose of moving
> > the document?
> >
> >

From: Birkir R. Gunnarsson
Date: Sat, Jul 14 2018 8:36AM
Subject: Re: Multiple documents in a single webpage
← Previous message | Next message →

I think it's fine to move focus to a document when it is displayed as
the result of activating a link or a button.
It would be bad if it is displayed as a result of changing the setting
of a component (selecting a radio button, checking a checkbox,
selecting from a dropdown etc.). You can see a lot of discussion about
this in the understanding WCAG SC 3.2.2 documentation.
You can enhance this by referencing visually hidden text on the button
that says "moves focus to the document display area".

I'd suggest to use something like role="region" and
aria-label="document" for the container element.
This is what aria-roledescription could be useful for, but so far it
has limited support and even does more harm than good (e.g. in IE it
overrides the semantics inside the document, with Jaws at least).

If you have
<div role="region" aria-roledescription="document panel"
aria-label="document name">
<h1>main heading</h1>
<p>text.</p>
<h2>Heading 2</h2>
...
</div>

an navigate to the headings inside the document, the headgs and levels
are no longer announced by Jaws, only the role description "document
panel" and the name.

Does the document region contain a button to close or move focus back
to the webpage?





On 7/13/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I think what Sean was asking about was moving the dialog itself. Since the
> dialog can be moved by dragging it or using the move handles (nice job
> allowing that from the keyboard), how does the AT user know where the
> dialog is now?
>
> With powerpoint, which I think I mentioned in some other thread, the
> location of the object is announced as you move it around. You're also
> notified if the object moves over the top or underneath another object. Is
> anything like that announced when you move your dialog? Is the dialog
> truly "on top" of the page in the background, or does stuff reflow around
> it as you move it around? If it's on top, when it first appears, does
> anything in the background get covered up? I'm guessing as you move it,
> other stuff on the main page might get covered up?
>
>
> On Fri, Jul 13, 2018 at 7:17 AM, Isabel Holdsworth <
> = EMAIL ADDRESS REMOVED = > wrote:
>
>> If we didn't move the focus, screenreader users would be unlikely to
>> know that some new content had appeared. And it may be difficult for
>> them to find. If they pressed the button to open the dialog, chances
>> are they're interested in what's in there, so why not position the
>> cursor so they can begin reading at the correct place?.
>>
>> The focus should rarely be moved programatically, but I think this is
>> one of those times when it's acceptable and even advisable.
>>
>> On 13/07/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>> > I have one question. How does the screen reader user know where they
>> > are
>> > when you move the document within the page? What is the purpose of
>> > moving
>> > the document?
>> >
>> >

From: Isabel Holdsworth
Date: Fri, Jul 20 2018 6:37AM
Subject: Re: Multiple documents in a single webpage
← Previous message | No next message

Apologies - it's been a while :-)

The position of the document isn't reported back to AT as it is
dragged. Nor do users know what's being covered up. Realistically, the
drag functionality is more for keyboard users who can see the screen.

The dialog sits on top of the originating document, and users will
most probably read the content in there and then close it before
continuing, but they do have the option to leave it open and drag it
somewhere unobtrusive such as to one side away from the main content.

Thanks as always, and have a great weekend.

On 14/07/2018, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> I think it's fine to move focus to a document when it is displayed as
> the result of activating a link or a button.
> It would be bad if it is displayed as a result of changing the setting
> of a component (selecting a radio button, checking a checkbox,
> selecting from a dropdown etc.). You can see a lot of discussion about
> this in the understanding WCAG SC 3.2.2 documentation.
> You can enhance this by referencing visually hidden text on the button
> that says "moves focus to the document display area".
>
> I'd suggest to use something like role="region" and
> aria-label="document" for the container element.
> This is what aria-roledescription could be useful for, but so far it
> has limited support and even does more harm than good (e.g. in IE it
> overrides the semantics inside the document, with Jaws at least).
>
> If you have
> <div role="region" aria-roledescription="document panel"
> aria-label="document name">
> <h1>main heading</h1>
> <p>text.</p>
> <h2>Heading 2</h2>
> ...
> </div>
>
> an navigate to the headings inside the document, the headgs and levels
> are no longer announced by Jaws, only the role description "document
> panel" and the name.
>
> Does the document region contain a button to close or move focus back
> to the webpage?
>
>
>
>
>
> On 7/13/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>> I think what Sean was asking about was moving the dialog itself. Since
>> the
>> dialog can be moved by dragging it or using the move handles (nice job
>> allowing that from the keyboard), how does the AT user know where the
>> dialog is now?
>>
>> With powerpoint, which I think I mentioned in some other thread, the
>> location of the object is announced as you move it around. You're also
>> notified if the object moves over the top or underneath another object.
>> Is
>> anything like that announced when you move your dialog? Is the dialog
>> truly "on top" of the page in the background, or does stuff reflow around
>> it as you move it around? If it's on top, when it first appears, does
>> anything in the background get covered up? I'm guessing as you move it,
>> other stuff on the main page might get covered up?
>>
>>
>> On Fri, Jul 13, 2018 at 7:17 AM, Isabel Holdsworth <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> If we didn't move the focus, screenreader users would be unlikely to
>>> know that some new content had appeared. And it may be difficult for
>>> them to find. If they pressed the button to open the dialog, chances
>>> are they're interested in what's in there, so why not position the
>>> cursor so they can begin reading at the correct place?.
>>>
>>> The focus should rarely be moved programatically, but I think this is
>>> one of those times when it's acceptable and even advisable.
>>>
>>> On 13/07/2018, = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = > wrote:
>>> > I have one question. How does the screen reader user know where they
>>> > are
>>> > when you move the document within the page? What is the purpose of
>>> > moving
>>> > the document?
>>> >
>>> >