Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Silvia Pfeiffer 
On Thu, Jul 7, 2011 at 12:40 PM, James Teh  wrote:
> On 7/07/2011 11:46 AM, Silvia Pfeiffer wrote:
>> I'm looking at aria-live mostly for
>> instructional purposes rather than for actually using it directly,
>> because I don't think it's possible to use it directly.
> I should clarify. I don't mean aria-live on the HTML side. Rather, I
> mean the way aria-live is exposed to ATs; i.e. an object gets marked as
> live.
>
>> Is the waiting-requirement indeed a use case of aria-live?
> Not of aria-live in HTML, no. However, I think we could generalise the
> "live" mechanism to things other than aria-live. In this case, an object
> would be marked as live but requiring notification/synchronisation. When
> the AT sees this, it would know to notify the object when it is done
> handling the live update.

I don't understand enough about it but it sounds like it could work.
So it would be an object with the descriptive text marked as live and
activated at the given entry time when the video reaches that entry
time? That notification/synchronisation mechanism is indeed the crux,
I think.

Silvia.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread James Teh 
On 7/07/2011 11:46 AM, Silvia Pfeiffer wrote:
> I'm looking at aria-live mostly for
> instructional purposes rather than for actually using it directly,
> because I don't think it's possible to use it directly.
I should clarify. I don't mean aria-live on the HTML side. Rather, I 
mean the way aria-live is exposed to ATs; i.e. an object gets marked as 
live.

> Is the waiting-requirement indeed a use case of aria-live?
Not of aria-live in HTML, no. However, I think we could generalise the 
"live" mechanism to things other than aria-live. In this case, an object 
would be marked as live but requiring notification/synchronisation. When 
the AT sees this, it would know to notify the object when it is done 
handling the live update.

Jamie

-- 
James Teh
Vice President, Developer
NV Access Inc, ABN 61773362390
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Silvia Pfeiffer 
On Thu, Jul 7, 2011 at 10:53 AM, James Teh  wrote:
> On 7/07/2011 10:43 AM, Silvia Pfeiffer wrote:
>>> I'm still not so keen on the pause
>>> while description is catching up behaviour. Part of this is
>>> design/implementation concerns; I'm very concerned about this tight
>>> interaction between the screen reader and the system. ...
>> The comparison to aria-live might work and might help find a better
>> solution.
> If this is to be done, I think this is the best approach. That said, I'm
> biased, as it was the idea I initially proposed. :)

I don't mind how it's done. I'm looking at aria-live mostly for
instructional purposes rather than for actually using it directly,
because I don't think it's possible to use it directly. But if you can
find a way, go for it. The effect needs to be the same, namely that
the video waits for the text to be finished reading. If aria-live can
make the video wait (maybe by making the complete web page wait or
something), that would solve that problem.


>> Is it possible to have aria-live regions be read out to the
>> end and have the Web page wait until it is finished? If so, that would
>> be the exact same mechanism that we require here.
> It's not currently possible, so we'd still have to introduce something
> new. However, I think extending an existing mechanism (thereby
> generalising it as much as possible) is better than introducing
> something entirely new, particularly as it seems to make sense.

Is the waiting-requirement indeed a use case of aria-live?

Silvia.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread James Teh 
On 7/07/2011 10:43 AM, Silvia Pfeiffer wrote:
>> I'm still not so keen on the pause
>> while description is catching up behaviour. Part of this is
>> design/implementation concerns; I'm very concerned about this tight
>> interaction between the screen reader and the system. ...
> The comparison to aria-live might work and might help find a better
> solution.
If this is to be done, I think this is the best approach. That said, I'm 
biased, as it was the idea I initially proposed. :)

> Is it possible to have aria-live regions be read out to the
> end and have the Web page wait until it is finished? If so, that would
> be the exact same mechanism that we require here.
It's not currently possible, so we'd still have to introduce something 
new. However, I think extending an existing mechanism (thereby 
generalising it as much as possible) is better than introducing 
something entirely new, particularly as it seems to make sense.

Jamie

-- 
James Teh
Vice President, Developer
NV Access Inc, ABN 61773362390
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Silvia Pfeiffer 
On Thu, Jul 7, 2011 at 10:23 AM, James Teh  wrote:
> On 7/07/2011 9:44 AM, Silvia Pfeiffer wrote:
>> I've not seen any cloud-based solutions for text descriptions.
>> While such an approach is possible, it relies on special services
>> offered by providers and is therefore not something that a Web browser
>> can rely on for having their content rendered.
> It also smells of non-standard to me, as well as requiring reliance on
> external services.
>
>> I do indeed believe that screen reader handling of text descriptions is
>> the best way forward.
> I agree for the most part, though I'm still not so keen on the pause
> while description is catching up behaviour. Part of this is
> design/implementation concerns; I'm very concerned about this tight
> interaction between the screen reader and the system. Generally, a
> screen reader is fairly passive in terms of its affect on the
> application without user action. Also, it could sometimes be extremely
> disruptive for the user.

I understand and that was exactly where my concerns are, too. I don't
know if there is a way around it, though.

The comparison to aria-live might work and might help find a better
solution. Is it possible to have aria-live regions be read out to the
end and have the Web page wait until it is finished? If so, that would
be the exact same mechanism that we require here.

Cheers,
Silvia.
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Silvia Pfeiffer 
On Thu, Jul 7, 2011 at 10:31 AM, Peter Korn  wrote:

> **
> Sylvia, all,
>
> My point with cloud-based TTS is... there are a number of TTS engines out
> there.  Some open source, some
> commercial-but-free/cheap-to-use-over-the-web.  Wouldn't it make for a much
> tighter integration & more powerful UI to have a media player that generates
> the TTS and automatically does the pausing/unpausing?
>


The media player is the Web browser. Do you mean that the Web browser should
generate the TTS or that a could service does the TTS? It seems you are
saying both, which doesn't make much sense to me. Can you clarify how you
see this working?


  Seems less complex than relying on screen reader vendors to support a new
> API that must first also be supported by the (HTML5 capable) browsers.
>

The specification in HTML5 already exists:
http://www.w3.org/TR/html5/video.html#attr-track-kind-keyword-descriptionsand
is starting to be implemented in browsers (
http://blog.gingertech.net/2011/06/27/recent-developments-around-webvtt/).

Also, I think using screen readers is a lot less complex than using a cloud
service for TTS, which has to hook into the browser's video element. But I
may be missing something - can you explain how that would work? The text
file that contains the text descriptions sits on a Web browser somewhere and
so does the video resource. How do you go from there to having it presented?

Silvia.

Cheers,
Silvia.



>
>
> Peter
>
>
> On 7/6/2011 5:23 PM, James Teh wrote:
>
> On 7/07/2011 9:44 AM, Silvia Pfeiffer wrote:
>
>  I've not seen any cloud-based solutions for text descriptions.
> While such an approach is possible, it relies on special services
> offered by providers and is therefore not something that a Web browser
> can rely on for having their content rendered.
>
>  It also smells of non-standard to me, as well as requiring reliance on
> external services.
>
>
>  I do indeed believe that screen reader handling of text descriptions is
> the best way forward.
>
>  I agree for the most part, though I'm still not so keen on the pause
> while description is catching up behaviour. Part of this is
> design/implementation concerns; I'm very concerned about this tight
> interaction between the screen reader and the system. Generally, a
> screen reader is fairly passive in terms of its affect on the
> application without user action. Also, it could sometimes be extremely
> disruptive for the user.
>
>
>  For non-deaf/blind users are there significant advantages of Braille
> over TTS such that TTS would not be a viable solution for providing
> text descriptions to a Braille user?
>
>  It could actually be useful if the user doesn't want the disruption to
> the audio that audio/TTS description causes. Braille could be a nice way
> of silently accessing the descriptions. However, as I noted before, I
> think a scrolling transcript is the best way to do this. The user can
> always disable scrolling if they wish or scroll back to read something
> they missed.
>
> Jamie
>
>
>
> --
> [image: Oracle] 
> Peter Korn | Accessibility Principal
> Phone: +1 650 5069522 <+1%20650%205069522>
> 500 Oracle Parkway | Redwood City, CA 94065
> [image: Green Oracle]  Oracle is
> committed to developing practices and products that help protect the
> environment
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>
<><>___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Peter Korn 


  
  
Sylvia, all,

My point with cloud-based TTS is... there are a number of TTS
engines out there.  Some open source, some
commercial-but-free/cheap-to-use-over-the-web.  Wouldn't it make for
a much tighter integration & more powerful UI to have a media
player that generates the TTS and automatically does the
pausing/unpausing?  Seems less complex than relying on screen reader
vendors to support a new API that must first also be supported by
the (HTML5 capable) browsers.


Peter

On 7/6/2011 5:23 PM, James Teh wrote:

  On 7/07/2011 9:44 AM, Silvia Pfeiffer wrote:

  
I've not seen any cloud-based solutions for text descriptions.
While such an approach is possible, it relies on special services
offered by providers and is therefore not something that a Web browser
can rely on for having their content rendered.

  
  It also smells of non-standard to me, as well as requiring reliance on 
external services.


  
I do indeed believe that screen reader handling of text descriptions is
the best way forward.

  
  I agree for the most part, though I'm still not so keen on the pause 
while description is catching up behaviour. Part of this is 
design/implementation concerns; I'm very concerned about this tight 
interaction between the screen reader and the system. Generally, a 
screen reader is fairly passive in terms of its affect on the 
application without user action. Also, it could sometimes be extremely 
disruptive for the user.


  
For non-deaf/blind users are there significant advantages of Braille
over TTS such that TTS would not be a viable solution for providing
text descriptions to a Braille user?

  
  It could actually be useful if the user doesn't want the disruption to 
the audio that audio/TTS description causes. Braille could be a nice way 
of silently accessing the descriptions. However, as I noted before, I 
think a scrolling transcript is the best way to do this. The user can 
always disable scrolling if they wish or scroll back to read something 
they missed.

Jamie




-- 
  
  Peter Korn | Accessibility Principal
Phone: +1 650 5069522 
500 Oracle Parkway | Redwood City, CA 94065
  
  
  Oracle is committed to developing practices and
products that help protect the environment
  
  

  

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread James Teh 
On 7/07/2011 9:44 AM, Silvia Pfeiffer wrote:
> I've not seen any cloud-based solutions for text descriptions.
> While such an approach is possible, it relies on special services
> offered by providers and is therefore not something that a Web browser
> can rely on for having their content rendered.
It also smells of non-standard to me, as well as requiring reliance on 
external services.

> I do indeed believe that screen reader handling of text descriptions is
> the best way forward.
I agree for the most part, though I'm still not so keen on the pause 
while description is catching up behaviour. Part of this is 
design/implementation concerns; I'm very concerned about this tight 
interaction between the screen reader and the system. Generally, a 
screen reader is fairly passive in terms of its affect on the 
application without user action. Also, it could sometimes be extremely 
disruptive for the user.

> For non-deaf/blind users are there significant advantages of Braille
> over TTS such that TTS would not be a viable solution for providing
> text descriptions to a Braille user?
It could actually be useful if the user doesn't want the disruption to 
the audio that audio/TTS description causes. Braille could be a nice way 
of silently accessing the descriptions. However, as I noted before, I 
think a scrolling transcript is the best way to do this. The user can 
always disable scrolling if they wish or scroll back to read something 
they missed.

Jamie

-- 
James Teh
Vice President, Developer
NV Access Inc, ABN 61773362390
Email: ja...@nvaccess.org
Web site: http://www.nvaccess.org/
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Silvia Pfeiffer 
I've not seen any cloud-based solutions for text descriptions. This would
require uploading the video and the text description file to a cloud
service, then have the could service render the text description file as
another audio track on the video and change the timing on the video at the
same time, then hand this all back to HTML and provide it in a @src on the
 or  element.

While such an approach is possible, it relies on special services offered by
providers and is therefore not something that a Web browser can rely on for
having their content rendered.

I have javascript demos of how to use aria-live regions with text
descriptions in the way that I would expect a screen reader to deal with
text descriptions.
You can see them here:
* http://www.html5videoguide.net/demos/google_io/2_audesc/
and
* http://www.annodex.net/~silvia/itext/elephant_no_skin_v2.html

Also, here's another example that somebody has done:
http://accessibility.oit.ncsu.edu/blog/2011/06/14/html-5-video-text-tracks-and-audio-descriptions-made-easy-or-at-least-easier/

I do indeed believe that screen reader handling of text descriptions is the
best way forward.

Regards,
Silvia.


On Thu, Jul 7, 2011 at 2:12 AM, Pete Brunet  wrote:

> **
> For non-deaf/blind users are there significant advantages of Braille over
> TTS such that TTS would not be a viable solution for providing text
> descriptions to a Braille user?  My initial hunch is that there is not.
>
> I am asking because if cloud based TTS, as suggested by Peter Korn, is an
> acceptable solution for providing text descriptions and if it's also
> acceptable for Braille users then there is no need to design a means to
> synch between the UA and a client based AT.
>
> Do we have enough experience with cloud based TTS to know that this is an
> acceptable solution?  If not, what is the current status of development and
> deployment?
>
> One concern might be latency.  This is a high priority issue for AT users.
>
> Pete
>
> This is in response to one of the many threads inside the "next changes to
> IAccessible2" thread...
>
> On 6/22/2011 11:51 AM, Pete Brunet wrote:
>
> Hi Peter, What is DAISY solution for Braille users?
>
> I'm also interested in pointers to web/cloud TTS solutions.
>
> Thanks, Pete
>
> On 6/22/2011 11:40 AM, Peter Korn wrote:
>
> Rich, Sylvia, all,
>
> I think we have identified the key use case for extended descriptions in
> HTML video playback: for blind people who can hear.  Deaf-blind would simply
> obtain all of the text (captions & extended descriptions) and read them at
> their own speed.
>
> All of this API discussion is predicated on the assumption that the blind
> user's screen reader should read these extended descriptions, with some
> programmatic means of pausing/continuing video playback while the screen
> reader reads the text (at a speed unknown to the video player).
>
> But is this really the right answer?  We are seeing more and more TTS
> engines available, many in the cloud.  Why not simply have the video player
> optionally read the extended description, pausing the video while it does
> so?  This is how we do DAISY book playback - we don't expect the screen
> reader to read the book, we expect the book player to read the text.  Also
> doing it this way makes the result much more universally available.  And it
> opens things up for a human being to read the extended descriptions - again
> similar to DAISY.
>
>
> Regards,
>
> Peter
>
> On 6/22/2011 6:27 AM, Richard Schwerdtfeger wrote:
>
> Pete,
>
> I am looking at accessibleDocument. Should we not do more than that for a
> document interface? Should we also have features to collect and access
> specific objects with a specific element type - filtering mechanisms?
>
> Note: I am in favor of not unnecessarily growing the API. API changes cause
> a lot of churn. However, with the FCC adopting creating new laws based on
> the 21st Century Communication and Video act there is a need for
> infrastructure to better support the HTML 5 changes Silvia is working on to
> support video and audio.
>
> I am looking at the notification mechanism for media
> MEDIA_TEXT_QUEUE_CHANGE. Would it be better to have a callback registry for
> ATs similar to what we did in Java? I am concerned about potential OS
> scheduling issues caused by posting events to the message queue.
>
>
>
>
> Rich Schwerdtfeger
> CTO Accessibility Software Group
>
> [image: Inactive hide details for Pete Brunet ---06/06/2011 11:12:32
> PM---Hi all, Please take a look at this and provide your feedback:]Pete
> Brunet ---06/06/2011 11:12:32 PM---Hi all, Please take a look at this and
> provide your feedback: https://wiki.mozilla.org/Accessibility
>
> From: Pete Brunet  
> To: IA2 List 
> 
> Date: 06/06/2011 11:12 PM
> Subject: Re: [Accessibility-ia2] next changes to IAccessible2
> Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
>  --
>
>
>
> Hi all, Please take a look at this and provide your feedback:

[Accessibility-ia2] solution for video text descriptions

2011-07-06 Thread Pete Brunet 


  
  
For non-deaf/blind users are there significant advantages of Braille
over TTS such that TTS would not be a viable solution for providing
text descriptions to a Braille user?  My initial hunch is that there
is not.

I am asking because if cloud based TTS, as suggested by Peter Korn,
is an acceptable solution for providing text descriptions and if
it's also acceptable for Braille users then there is no need to
design a means to synch between the UA and a client based AT.

Do we have enough experience with cloud based TTS to know that this
is an acceptable solution?  If not, what is the current status of
development and deployment?

One concern might be latency.  This is a high priority issue for AT
users.

Pete

This is in response to one of the many threads inside the "next
changes to IAccessible2" thread...

On 6/22/2011 11:51 AM, Pete Brunet wrote:

  
  Hi Peter, What is DAISY solution for Braille users?
  
  I'm also interested in pointers to web/cloud TTS solutions.
  
  Thanks, Pete
  
  On 6/22/2011 11:40 AM, Peter Korn wrote:
  

Rich, Sylvia, all,

I think we have identified the key use case for extended
descriptions in HTML video playback: for blind people who can
hear.  Deaf-blind would simply obtain all of the text (captions
& extended descriptions) and read them at their own speed.

All of this API discussion is predicated on the assumption that
the blind user's screen reader should read these extended
descriptions, with some programmatic means of pausing/continuing
video playback while the screen reader reads the text (at a
speed unknown to the video player).

But is this really the right answer?  We are seeing more and
more TTS engines available, many in the cloud.  Why not simply
have the video player optionally read the extended description,
pausing the video while it does so?  This is how we do DAISY
book playback - we don't expect the screen reader to read the
book, we expect the book player to read the text.  Also doing it
this way makes the result much more universally available.  And
it opens things up for a human being to read the extended
descriptions - again similar to DAISY.


Regards,

Peter

On 6/22/2011 6:27 AM, Richard Schwerdtfeger wrote:

  Pete, 

I am looking at
  accessibleDocument. Should we not do more than that for a
  document interface? Should we also have features to
  collect and access specific objects with a specific
  element type - filtering mechanisms?

Note: I am in favor of not
  unnecessarily growing the API. API changes cause a lot of
  churn. However, with the FCC adopting creating new laws
  based on the 21st Century Communication and Video act
  there is a need for infrastructure to better support the
  HTML 5 changes Silvia is working on to support video and
  audio.

I am looking at the
  notification mechanism for media MEDIA_TEXT_QUEUE_CHANGE.
  Would it be better to have a callback registry for ATs
  similar to what we did in Java? I am concerned about
  potential OS scheduling issues caused by posting events to
  the message queue. 



  
  Rich Schwerdtfeger
  CTO Accessibility Software Group

Pete Brunet
  ---06/06/2011 11:12:32 PM---Hi all, Please take a look at
  this and provide your feedback: https://wiki.mozilla.org/Accessibility

From: Pete Brunet 
To: IA2 List 
Date: 06/06/2011 11:12 PM
Subject: Re: [Accessibility-ia2] next
  changes to IAccessible2
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
  
  
  
  
  Hi all, Please take a look at this
and provide your feedback:
  
https://wiki.mozilla.org/Accessibility/IA2_1.3

Thanks, Pete
  -- 
  Pete Brunet

a11ysoft - Accessibility Architecture and Development
(512) 238-6967 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G 
  
On 3/11/2011 11:10 PM, Alexander Surkov wrote: 
  
Hi, Jamie. I missed Mick

Re: [Accessibility-ia2] Braille devices and live regions

2011-07-06 Thread Pete Brunet 


  
  
HI Rich,  was referring to Sylvia's request to handle the streaming
of text descriptions which are the text equivalent of audio
descriptions used to describe visual content which is not obvious
from a video's audio track.  The text descriptions are not displayed
and meant for consumption by an AT.  The UA's video renderer would
signal the availability of each new text description as it is
encountered in the video track and the UA would then fire a
WinEvent.

This is a non-traditional scenario for a Braille user, but it's
similar to the case of a live region so I was interested in the live
region UX for the Braille user.  After reading what Jamie said I
think the experience would be:  the user enables text descriptions
via a standard UI mechanism, activates a video via another standard
UI mechanism, and then places his hands on the Braille display
waiting for the text descriptions.

After reading a text description the user would signal readiness for
more content (because the UA pauses the video until the TTS is done
or the Braille user is done).  I don' t know how that would be
accomplished.  What UI means have Braille device managers provided
for the Braille user to move the POR (point of regard) from the live
region back to the prior POR?  Perhaps in the case of text
descriptions the same method could be used to signal that the user
is ready for the video to continue.

Pete

On 7/6/2011 8:00 AM, Richard Schwerdtfeger wrote:

  Pete, 

We do have text changes
  available in ARIA. When you say text descriptions are you
  thinking of:

- Things like Stock tickers?
- Captions?

In live regions we do notify of
  text changes. It sounds like you want to know when an entire
  entity of text changes of semantic importance. If you were
  going to do that the application needs to make the
  notification. This would require a new event. 

What are you think would
  trigger a notification when you are streaming text?

Rich

  
  Rich Schwerdtfeger
  CTO Accessibility Software Group

Pete Brunet
  ---07/05/2011 09:55:14 PM---Regarding steaming text
  descriptions to Braille devices, the user would have to be
  notified that a n

From: Pete Brunet
  
To: IA2 List
  
Date: 07/05/2011 09:55 PM
Subject: [Accessibility-ia2] Braille devices
  and live regions
Sent by: accessibility-ia2-boun...@lists.linuxfoundation.org
  
  
  
  
  Regarding steaming text descriptions
to Braille devices, the user would have to be notified that a
new description is available. Is there a means to notify Braille
users of updated contents that are available for access? This
would be a similar scenario to live regions. How is a Braille
user notified of a live region update?
  -- 
  Pete Brunet

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G ___
  Accessibility-ia2 mailing list
  Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2



-- 
  Pete
  Brunet
  
    
    
    
    
  

  
a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G

  

  

___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Braille devices and live regions

2011-07-06 Thread Richard Schwerdtfeger 

Pete,

We do have text changes available in ARIA. When you say text descriptions
are you thinking of:

- Things like Stock tickers?
- Captions?

In live regions we do notify of text changes. It sounds like you want to
know when an entire entity of text changes of semantic importance. If you
were going to do that the application needs to make the notification. This
would require a new event.

What are you think would trigger a notification when you are streaming
text?

Rich

Rich Schwerdtfeger
CTO Accessibility Software Group



From:   Pete Brunet 
To: IA2 List 
Date:   07/05/2011 09:55 PM
Subject:[Accessibility-ia2] Braille devices and live regions
Sent by:accessibility-ia2-boun...@lists.linuxfoundation.org



Regarding steaming text descriptions to Braille devices, the user would
have to be notified that a new description is available.  Is there a means
to notify Braille users of updated contents that are available for access?
This would be a similar scenario to live regions.  How is a Braille user
notified of a live region update?
--
Pete Brunet

a11ysoft - Accessibility Architecture and Development
(512) 467-4706 (work), (512) 689-4155 (cell)
Skype: pete.brunet
IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
http://www.a11ysoft.com/about/
Ionosphere: WS4G ___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
<>___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2

Re: [Accessibility-ia2] Fwd: reorder events issue

2011-07-06 Thread Alexander Surkov 
Hi, Pete.

I didn't find background in mozilla bugzilla, I think this feature was
discussed over irc I think. IA2 list has Jamie's concern -
https://lists.linux-foundation.org/pipermail/accessibility-ia2/2011-June/001340.html.
It appears this feature should have more discussions.

Thank you.
Alex.


On Tue, Jul 5, 2011 at 11:36 PM, Pete Brunet  wrote:

> **
> Hi Alex, I went through the IA2 list archives and couldn't find the
> background on this.  Is the history in a Mozilla bug perhaps?  -Pete
>
>  Original Message   Subject: reorder events issue  Date: Wed,
> 29 Jun 2011 16:07:53 -0500  From: Pete Brunet 
>   Reply-To:
> p...@a11ysoft.com  CC: IAccessible2 mailing list
> 
>
>
> Alex, I don't remember the founding discussions for the reorder events
> issue.  Please update the proposal wiki page with a link to that
> discussion.  Thanks, Pete
>
> On 6/8/2011 3:53 AM, Alexander Surkov wrote:
>
> Hi, Jamie.
>
> If two continue set of children are added and removed then you get an
> array of two items IA2ChildrenChange.
>
> What's the problem of in-process calls?
>
> If you think this suggestion doesn't make too much sense then it's
> fine and let's drop it from proposal. But since this problem is bottle
> neck on certain cases, then we should start working on alternative
> way.
>
> Thank you.
> Alex.
>
>
> On Wed, Jun 8, 2011 at 5:34 PM, James Teh  
>  wrote:
>
>  Regarding Reorder event 
> details:https://wiki.mozilla.org/Accessibility/IA2_1.3#Reorder_event_details
>
> One issue is that this introduces more in-process only calls into IA2.
> That is, you can of course make the call out-of-process, but it isn't
> useful because win events are async. I don't really have a solution to
> this problem without creating a new event system, but I think this is
> something worth noting nevertheless. :)
>
> Also, I think the way this works needs to be clarified; e.g. what
> happens if children are both added and removed.
>
> Jamie
>
> On 7/06/2011 2:09 PM, Pete Brunet wrote:
>
>  Hi all, Please take a look at this and provide your feedback:
> https://wiki.mozilla.org/Accessibility/IA2_1.3
>
> Thanks, Pete
> --
> *Pete Brunet*
>
> a11ysoft - Accessibility Architecture and Development
> (512) 238-6967 (work), (512) 689-4155 (cell)
> Skype: pete.brunet
> IM: ptbrunet (AOL, Google), ptbru...@live.com 
> (MSN)http://www.a11ysoft.com/about/
> Ionosphere: WS4G
>
> On 3/11/2011 11:10 PM, Alexander Surkov wrote:
>
>  Hi, Jamie. I missed Mick suggestion on the list. It's sounds
> reasonable and I agree we should try it before getting new API for
> this since the issue is mostly about events.
>
> Thank you.
> Alex.
>
>
> On Sat, Mar 12, 2011 at 11:43 AM, James Teh 
> mailto:ja...@nvaccess.org> > wrote:
>
> Hi.
>
> Nice work; good to get the discussion going. :)
>
> I still don't see a need for this registry API. Why not just use
> IsWinEventHookInstalled(), as Mick suggested on the IA2 list?
>
> Thanks.
>
> Jamie
>
>
> On 12/03/2011 3:48 AM, Alexander Surkov wrote:
>
> Hi.
>
> I gathered ideas into one doc -
> https://wiki.mozilla.org/Accessibility/IA2_1.3. Please give
> feedback
> here and feel free to edit the wiki.
>
> Thank you.
> Alex.
>
>
> --
> James Teh
> Vice President, Developer
> NV Access Inc, ABN 61773362390
> Email: ja...@nvaccess.org  
> Web site: http://www.nvaccess.org/
>
>  ___
> Accessibility-ia2 mailing 
> listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>  --
> James Teh
> Vice President, Developer
> NV Access Inc, ABN 61773362390
> Email: ja...@nvaccess.org
> Web site: http://www.nvaccess.org/
> ___
> Accessibility-ia2 mailing 
> listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>  ___
> Accessibility-ia2 mailing 
> listAccessibility-ia2@lists.linuxfoundation.orghttps://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>
> --
> *Pete Brunet*
>
>  a11ysoft - Accessibility Architecture and Development
> (512) 689-4155 (cell)
> Skype: pete.brunet
> IM: ptbrunet (AOL, Google), ptbru...@live.com (MSN)
> http://www.a11ysoft.com/about/
> Ionosphere: WS4G
>
> ___
> Accessibility-ia2 mailing list
> Accessibility-ia2@lists.linuxfoundation.org
> https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2
>
>
___
Accessibility-ia2 mailing list
Accessibility-ia2@lists.linuxfoundation.org
https://lists.linux-foundation.org/mailman/listinfo/accessibility-ia2