correspondance with Aaron Leventhal

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

correspondance with Aaron Leventhal

Hans Hillen
Hi everyone

Aaron asked me to post a mail I sent to him here on the list so others can
read it. It kind of explains what I've been working on lately. Chances are I
will be joining the CSUN 2006 conference after all, so I hope to meet
everybody there and exchange ideas.

Hans

--------
Aaron Leventhal wrote:

Hans,

Do you mind posting this summary to the mozilla.dev.accessibility
newsgroup so other developers can see what you're working on? I have a
feeling that a lot of collaboration is possible.

- Aaron

-----------
Hans Hillen wrote:

Hi Aron

Thank you for your interest.  I'll tell you a little more about myself. I'm
a master student in social science informatics, at the University of
Amsterdam, the Netherlands. For the last year I've been working on my final
thesis, which 'should' be completed in about a month. I'll give you a
description of what my research is about, and will try to keep it short

Based on my literature study I found that blind Internet users had problems
navigating through a site because the lack of overview on a site. I
developed a tool called 'NavAccess' which provided an alternative,
audio-based interface to a website's navigational structure, which didn't
focus on a specific page but on the entire 'infrastructure' of a website as
a whole. The idea was that by this separate interface, blind users would be
able to navigate more efficiently and effectively, as this interface was
consistent and easy to use (the controls were based on the right numpad,
navigation between pages was done with arrow keys). It was expected that by
switching back and forth between my tool and the browser window, two
different navigation styles could be applied:

1. The NavAccess style, which allowed for fast navigation, but with a low
level of detail
2. The 'normal' browser style, which was high in detail but therefore also
slower to use

I thought that users could use style 1 (my tool) to quickly get a better
overview of a site's navigational structure (a 'macoanalysis'), and when
they located a specific page of interest, they have this page opened in the
main browser to study it in more detail using style 2 (a 'microanalysis').

The tool consisted of a server part (written in PHP) which crawled through a
website, following each link and collecting information about each page it
encountered. All this information was stored in an XML file which was then
parsed by the client part of the tool (written in Python), which provided
the interface to the user. This interface basiclly functioned as a link
list, only not just for a page but for an entire site. The user could go
through the links and follow them using the arrow keys, without the pages
having to actually load in the browser.

Besides the main navigation the tool provided extra side functions:

- Specific controls were available to reach a site's main category pages, as
well as it's main (home)  page. This way users did not have to search for a
specific link on the page pointing to those locations.
- Link title alternatives could be requested (e.g. the title of the target
page) to make links without a title (such as linked images) easier to
comprehend.
- Link preview information was given through sound about a specific link's
target, such as whether the link was broken, pointing to a page outside the
current website domain, pointing to a file other than html (i.e. jpeg or pdf
files), based on a scheme other than http (i.e. ftp or mailto).
- The textual context of a link could be requested, meaning that instead of
only hearing 'here', the link was mentioned as a part of the sentence (click
'here' to bla bla bla)

I tested the first prototype with a small user sample, and suffice it to say
that my tool didn't really improve the navigational performance of my
participants , but instead made things more complex for them. However, the
additional side functions mentioned above did prove to be beneficial, and
some mentioned they would like to see them as integrated functions of their
browser or screen reader. Since the NavAccess tool was not very practical to
begin with (it could take an hour to crawl through a large website
(contaning 1000 or more pages), leading to huge XML files which took long to
load, etc. So I decided to stop its development and focus on a new prototype
which offered more lightweight solutions, based on the things I learned
during  my research so far (and the guidelines which I developed based on
this new knowledge). Such a prototype could then actually be used in and be
helpful real life rather than only in an experimental environment. Because I
have to graduate soon I decided to only implement a small example of what
the final prototype should be like, and that is what I'm doing now. Since
JAWS version 7 and Firefox version 1.5 have been released in the meantime, I
thought it would be a good idea to get rid of my Python stuff and implement
this new prototype as a Firefox extension, which can then be expanded with
extra functionality after I graduate (either by me or more experienced
programmers). Currently I'm working on ways to make the JAWS linklist richer
in functionality, as you could read in my post.

I would love to go to CSUN, unfortunately I just returned from a 3 months
stay at Stanford Uni and don't really have the means to go back to the
states right now.  I guess my timing could have been better.

As for nsIAccessible, I don't really know what I would like to do with it,
because I still don't understand what its functions can  do exactly. I
suppose I would like to have more control over what JAWS says, when it says
it and when it knows to be silent. I don't really have any experience with
XPCOM in general, which is why the xpcom reference on xulplanet is a bit too
vague for me. I guess it would be nice to just see some examples of how the
nsIAccessible interface can be used.

I hadn't really looked into the extensions you mentioned yet, but I'm
definitely going to check their code to see if I can learn from it.

Thanks again for the interest!

Hans


_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

Re: correspondance with Aaron Leventhal

Aaron Leventhal-3
Hans,

That sounds really interesting. From my perspective it would be great if
your code could be kept alive after you move on, perhaps inside another
extension.

- Aaron


Hans Hillen wrote:

> Hi everyone
>
> Aaron asked me to post a mail I sent to him here on the list so others can
> read it. It kind of explains what I've been working on lately. Chances are I
> will be joining the CSUN 2006 conference after all, so I hope to meet
> everybody there and exchange ideas.
>
> Hans
>
> --------
> Aaron Leventhal wrote:
>
> Hans,
>
> Do you mind posting this summary to the mozilla.dev.accessibility
> newsgroup so other developers can see what you're working on? I have a
> feeling that a lot of collaboration is possible.
>
> - Aaron
>
> -----------
> Hans Hillen wrote:
>
> Hi Aron
>
> Thank you for your interest.  I'll tell you a little more about myself. I'm
> a master student in social science informatics, at the University of
> Amsterdam, the Netherlands. For the last year I've been working on my final
> thesis, which 'should' be completed in about a month. I'll give you a
> description of what my research is about, and will try to keep it short
>
> Based on my literature study I found that blind Internet users had problems
> navigating through a site because the lack of overview on a site. I
> developed a tool called 'NavAccess' which provided an alternative,
> audio-based interface to a website's navigational structure, which didn't
> focus on a specific page but on the entire 'infrastructure' of a website as
> a whole. The idea was that by this separate interface, blind users would be
> able to navigate more efficiently and effectively, as this interface was
> consistent and easy to use (the controls were based on the right numpad,
> navigation between pages was done with arrow keys). It was expected that by
> switching back and forth between my tool and the browser window, two
> different navigation styles could be applied:
>
> 1. The NavAccess style, which allowed for fast navigation, but with a low
> level of detail
> 2. The 'normal' browser style, which was high in detail but therefore also
> slower to use
>
> I thought that users could use style 1 (my tool) to quickly get a better
> overview of a site's navigational structure (a 'macoanalysis'), and when
> they located a specific page of interest, they have this page opened in the
> main browser to study it in more detail using style 2 (a 'microanalysis').
>
> The tool consisted of a server part (written in PHP) which crawled through a
> website, following each link and collecting information about each page it
> encountered. All this information was stored in an XML file which was then
> parsed by the client part of the tool (written in Python), which provided
> the interface to the user. This interface basiclly functioned as a link
> list, only not just for a page but for an entire site. The user could go
> through the links and follow them using the arrow keys, without the pages
> having to actually load in the browser.
>
> Besides the main navigation the tool provided extra side functions:
>
> - Specific controls were available to reach a site's main category pages, as
> well as it's main (home)  page. This way users did not have to search for a
> specific link on the page pointing to those locations.
> - Link title alternatives could be requested (e.g. the title of the target
> page) to make links without a title (such as linked images) easier to
> comprehend.
> - Link preview information was given through sound about a specific link's
> target, such as whether the link was broken, pointing to a page outside the
> current website domain, pointing to a file other than html (i.e. jpeg or pdf
> files), based on a scheme other than http (i.e. ftp or mailto).
> - The textual context of a link could be requested, meaning that instead of
> only hearing 'here', the link was mentioned as a part of the sentence (click
> 'here' to bla bla bla)
>
> I tested the first prototype with a small user sample, and suffice it to say
> that my tool didn't really improve the navigational performance of my
> participants , but instead made things more complex for them. However, the
> additional side functions mentioned above did prove to be beneficial, and
> some mentioned they would like to see them as integrated functions of their
> browser or screen reader. Since the NavAccess tool was not very practical to
> begin with (it could take an hour to crawl through a large website
> (contaning 1000 or more pages), leading to huge XML files which took long to
> load, etc. So I decided to stop its development and focus on a new prototype
> which offered more lightweight solutions, based on the things I learned
> during  my research so far (and the guidelines which I developed based on
> this new knowledge). Such a prototype could then actually be used in and be
> helpful real life rather than only in an experimental environment. Because I
> have to graduate soon I decided to only implement a small example of what
> the final prototype should be like, and that is what I'm doing now. Since
> JAWS version 7 and Firefox version 1.5 have been released in the meantime, I
> thought it would be a good idea to get rid of my Python stuff and implement
> this new prototype as a Firefox extension, which can then be expanded with
> extra functionality after I graduate (either by me or more experienced
> programmers). Currently I'm working on ways to make the JAWS linklist richer
> in functionality, as you could read in my post.
>
> I would love to go to CSUN, unfortunately I just returned from a 3 months
> stay at Stanford Uni and don't really have the means to go back to the
> states right now.  I guess my timing could have been better.
>
> As for nsIAccessible, I don't really know what I would like to do with it,
> because I still don't understand what its functions can  do exactly. I
> suppose I would like to have more control over what JAWS says, when it says
> it and when it knows to be silent. I don't really have any experience with
> XPCOM in general, which is why the xpcom reference on xulplanet is a bit too
> vague for me. I guess it would be nice to just see some examples of how the
> nsIAccessible interface can be used.
>
> I hadn't really looked into the extensions you mentioned yet, but I'm
> definitely going to check their code to see if I can learn from it.
>
> Thanks again for the interest!
>
> Hans
>
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|

correspondance with Aaron Leventhal

T. V. Raman-2
In reply to this post by Hans Hillen
Hans,

Another good resource for gathering such information from Web
sites might be any sitemaps they publish to help crawlers and
search engines

>>>>> "Hans" == Hans Hillen <[hidden email]> writes:
    Hans> Hi everyone Aaron asked me to post a mail I sent to him
    Hans> here on the list so others can read it. It kind of
    Hans> explains what I've been working on lately. Chances are
    Hans> I will be joining the CSUN 2006 conference after all,
    Hans> so I hope to meet everybody there and exchange ideas.
    Hans>
    Hans> Hans
    Hans>
    Hans> -------- Aaron Leventhal wrote:
    Hans>
    Hans> Hans,
    Hans>
    Hans> Do you mind posting this summary to the
    Hans> mozilla.dev.accessibility newsgroup so other developers
    Hans> can see what you're working on? I have a feeling that a
    Hans> lot of collaboration is possible.
    Hans>
    Hans> - Aaron
    Hans>
    Hans> ----------- Hans Hillen wrote:
    Hans>
    Hans> Hi Aron
    Hans>
    Hans> Thank you for your interest.  I'll tell you a little
    Hans> more about myself. I'm a master student in social
    Hans> science informatics, at the University of Amsterdam,
    Hans> the Netherlands. For the last year I've been working on
    Hans> my final thesis, which 'should' be completed in about a
    Hans> month. I'll give you a description of what my research
    Hans> is about, and will try to keep it short
    Hans>
    Hans> Based on my literature study I found that blind
    Hans> Internet users had problems navigating through a site
    Hans> because the lack of overview on a site. I developed a
    Hans> tool called 'NavAccess' which provided an alternative,
    Hans> audio-based interface to a website's navigational
    Hans> structure, which didn't focus on a specific page but on
    Hans> the entire 'infrastructure' of a website as a
    Hans> whole. The idea was that by this separate interface,
    Hans> blind users would be able to navigate more efficiently
    Hans> and effectively, as this interface was consistent and
    Hans> easy to use (the controls were based on the right
    Hans> numpad, navigation between pages was done with arrow
    Hans> keys). It was expected that by switching back and forth
    Hans> between my tool and the browser window, two different
    Hans> navigation styles could be applied:
    Hans>
    Hans> 1. The NavAccess style, which allowed for fast
    Hans> navigation, but with a low level of detail 2. The
    Hans> 'normal' browser style, which was high in detail but
    Hans> therefore also slower to use
    Hans>
    Hans> I thought that users could use style 1 (my tool) to
    Hans> quickly get a better overview of a site's navigational
    Hans> structure (a 'macoanalysis'), and when they located a
    Hans> specific page of interest, they have this page opened
    Hans> in the main browser to study it in more detail using
    Hans> style 2 (a 'microanalysis').
    Hans>
    Hans> The tool consisted of a server part (written in PHP)
    Hans> which crawled through a website, following each link
    Hans> and collecting information about each page it
    Hans> encountered. All this information was stored in an XML
    Hans> file which was then parsed by the client part of the
    Hans> tool (written in Python), which provided the interface
    Hans> to the user. This interface basiclly functioned as a
    Hans> link list, only not just for a page but for an entire
    Hans> site. The user could go through the links and follow
    Hans> them using the arrow keys, without the pages having to
    Hans> actually load in the browser.
    Hans>
    Hans> Besides the main navigation the tool provided extra
    Hans> side functions:
    Hans>
    Hans> - Specific controls were available to reach a site's
    Hans> main category pages, as well as it's main (home)
    Hans> page. This way users did not have to search for a
    Hans> specific link on the page pointing to those locations.
    Hans> - Link title alternatives could be requested (e.g. the
    Hans> title of the target page) to make links without a title
    Hans> (such as linked images) easier to comprehend.  - Link
    Hans> preview information was given through sound about a
    Hans> specific link's target, such as whether the link was
    Hans> broken, pointing to a page outside the current website
    Hans> domain, pointing to a file other than html (i.e. jpeg
    Hans> or pdf files), based on a scheme other than http
    Hans> (i.e. ftp or mailto).  - The textual context of a link
    Hans> could be requested, meaning that instead of only
    Hans> hearing 'here', the link was mentioned as a part of the
    Hans> sentence (click 'here' to bla bla bla)
    Hans>
    Hans> I tested the first prototype with a small user sample,
    Hans> and suffice it to say that my tool didn't really
    Hans> improve the navigational performance of my participants
    Hans> , but instead made things more complex for
    Hans> them. However, the additional side functions mentioned
    Hans> above did prove to be beneficial, and some mentioned
    Hans> they would like to see them as integrated functions of
    Hans> their browser or screen reader. Since the NavAccess
    Hans> tool was not very practical to begin with (it could
    Hans> take an hour to crawl through a large website
    Hans> (contaning 1000 or more pages), leading to huge XML
    Hans> files which took long to load, etc. So I decided to
    Hans> stop its development and focus on a new prototype which
    Hans> offered more lightweight solutions, based on the things
    Hans> I learned during my research so far (and the guidelines
    Hans> which I developed based on this new knowledge). Such a
    Hans> prototype could then actually be used in and be helpful
    Hans> real life rather than only in an experimental
    Hans> environment. Because I have to graduate soon I decided
    Hans> to only implement a small example of what the final
    Hans> prototype should be like, and that is what I'm doing
    Hans> now. Since JAWS version 7 and Firefox version 1.5 have
    Hans> been released in the meantime, I thought it would be a
    Hans> good idea to get rid of my Python stuff and implement
    Hans> this new prototype as a Firefox extension, which can
    Hans> then be expanded with extra functionality after I
    Hans> graduate (either by me or more experienced
    Hans> programmers). Currently I'm working on ways to make the
    Hans> JAWS linklist richer in functionality, as you could
    Hans> read in my post.
    Hans>
    Hans> I would love to go to CSUN, unfortunately I just
    Hans> returned from a 3 months stay at Stanford Uni and don't
    Hans> really have the means to go back to the states right
    Hans> now.  I guess my timing could have been better.
    Hans>
    Hans> As for nsIAccessible, I don't really know what I would
    Hans> like to do with it, because I still don't understand
    Hans> what its functions can do exactly. I suppose I would
    Hans> like to have more control over what JAWS says, when it
    Hans> says it and when it knows to be silent. I don't really
    Hans> have any experience with XPCOM in general, which is why
    Hans> the xpcom reference on xulplanet is a bit too vague for
    Hans> me. I guess it would be nice to just see some examples
    Hans> of how the nsIAccessible interface can be used.
    Hans>
    Hans> I hadn't really looked into the extensions you
    Hans> mentioned yet, but I'm definitely going to check their
    Hans> code to see if I can learn from it.
    Hans>
    Hans> Thanks again for the interest!
    Hans>
    Hans> Hans
    Hans>
    Hans>
    Hans> _______________________________________________
    Hans> dev-accessibility mailing list
    Hans> [hidden email]
    Hans> https://lists.mozilla.org/listinfo/dev-accessibility

--
Best Regards,
--raman

     
Email:  [hidden email]
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: [hidden email]
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility