RE: [Cloud Browser] added categorized use cases for communication

Greetings all,

 

I’d like to take this opportunity to focus (again) on some high-level accessibility requirements as part of the use-case requirements gathering. 

 

Broadly speaking, accessibility requirements for a “cloud browser” would be covered in the following WAI Domain Notes:

*        User Agent Accessibility Guidelines (UAAG) 2.0 | (W3C Working Group Note 15 December 2015): https://www.w3.org/TR/UAAG20/ 

*        Media Accessibility User Requirements | (W3C Working Group Note 03 December 2015): https://www.w3.org/TR/media-accessibility-reqs/ 

 

A cloud-based browser will need to be both input and output agnostic, which is to say that the interaction or input mode should not require a single method of providing input or content rendering. 

 

For example it should support (say) both speech input, as well as perhaps an on-screen keyboard, which can be activated by an alternative switching device that *may* be a TV controller or similar, but it will need to also support other types of devices (for example, if a user has no upper-body control, or perhaps an amputee, etc., then they might use foot switches:  <https://www.google.com/search?q=foot+switch+for+computers&espv=2&biw=1920&bih=945&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiau7ie6ZDLAhWhtYMKHRcJDDgQ_AUIBygC> https://www.google.com/search?q=foot+switch+for+computers&espv=2&biw=1920&bih=945&source=lnms&tbm=isch&sa=X&ved=0ahUKEwiau7ie6ZDLAhWhtYMKHRcJDDgQ_AUIBygC)  

 

Equally, it must account for the Accessibility APIs that are currently native to most computing operating systems (but may NOT be part of onboard TV systems, etc.). This is critical for many users, especially non-sighted users that rely on screen reading software - which itself may be a HUGE problem if envisioned systems do not allow for the insertion of third-party software. In that case, the cloud browser will likely need to account for that functionality directly (in perhaps a fashion similar to how VoiceOver is part of iOS/MacOS). There are web-based solutions today that may also be worth investigating (see:  <https://sitecues.com/product/> https://sitecues.com/product/ as but one example)

 

At a slightly more granular level, please see (from the Media Accessibility User Requirements):

*         <https://www.w3.org/TR/media-accessibility-reqs/#requirements-on-secondary-screens-and-other-devices> https://www.w3.org/TR/media-accessibility-reqs/#requirements-on-secondary-screens-and-other-devices

*         <https://www.w3.org/TR/media-accessibility-reqs/#access-to-interactive-controls-menus> https://www.w3.org/TR/media-accessibility-reqs/#access-to-interactive-controls-menus 

*         <https://www.w3.org/TR/media-accessibility-reqs/#requirements-on-making-properties-available-to-the-accessibility-interface> https://www.w3.org/TR/media-accessibility-reqs/#requirements-on-making-properties-available-to-the-accessibility-interface

(Note, when we were gathering these requirements, we were operating under the presumption of interaction with HTML 5’s <video> element and related functionality, however I believe the key points addressed have relevance to this group)

 

And from the User Agent Accessibility Guidelines:

*         <https://www.w3.org/TR/UAAG10/intro.html#user-control> https://www.w3.org/TR/UAAG10/intro.html#user-control

*         <https://www.w3.org/TR/UAAG10/guidelines.html#gl-device-independence> https://www.w3.org/TR/UAAG10/guidelines.html#gl-device-independence

*         <https://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui> https://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui 

*         <https://www.w3.org/TR/UAAG10/guidelines.html#gl-navigation> https://www.w3.org/TR/UAAG10/guidelines.html#gl-navigation 

*         <https://www.w3.org/TR/UAAG10/guidelines.html#gl-configuration> https://www.w3.org/TR/UAAG10/guidelines.html#gl-configuration 

(Note: I could easily quote the entire UAAG Note as relevant, and I recommend that it be reviewed by this larger group – I would be happy to provide any clarification or explanation as required. The above 5 bullet points taken from UAAG are likely the most relevant/critical at this time)

 

Colin, I’d be happy to try and work this into the wiki if you’d like, or I could work with you or someone else to tailor it to the larger needs of this group – please let me know.

 

Cheers!

 

JF

​-- 

John Foliot

Principal Accessibility Strategist

Austin, TX

 

Deque Systems Inc.
2121 Cooperative Way, Suite 210,  
Herndon, VA 20171-5344

Office: 703-225-0380 

 <mailto:john.foliot@deque.com> john.foliot@deque.com

 

Advancing the mission of digital accessibility and inclusion

 

 

 

 

From: Meerveld, Colin [mailto:C.Meerveld@activevideo.com] 
Sent: Wednesday, February 24, 2016 9:50 AM
To: Ronen Mizrahi <ronen@tversity.com>
Cc: public-web-and-tv@w3.org
Subject: Re: [Cloud Browser] added categorised use cases for communication

 

Hi Ronen,

 

Thank you for your reply. I fully agree, that we need specific use cases to identify gaps. My concern is when we dive into the specifics right away we could lose track. That is why i proposed to start with more generic use cases (you may call them high-level requirements). Especially because a cloud-browser should have (potentially) the same functionality as a conventional browser and therefore endless use cases.

 

Regards,

 

Colin Meerveld

 

On 23 Feb 2016, at 16:46, Ronen Mizrahi <ronen@tversity.com <mailto:ronen@tversity.com> > wrote:

 

Hi All, 

 

While I did not participate in the call, I think the use-cases Colin refers to as "specific" such as running a video app (like YouTube for TV or Netflix) or web-conferencing are important and should be the starting point of the analysis. Although they are just a tool to identify gaps and come up with a list of requirements, they have a very important role to play because they tie the system to real-world situations in which the system should be able to operate.

 

The more generic use-cases (like input, output, syncing and hand-off functionality) are in fact not use-cases at all but rather they are already high-level requirements. These high-level requirements will need to become detailed requirements that properly address the full range of real-world scenarios in which the system should operate. In my opinion it won't be possible to do this properly without going through the "specific" use-cases.

 

Best Regards,

 

Ronen Mizrahi

 

On Tue, Feb 23, 2016 at 8:38 AM, Meerveld, Colin <C.Meerveld@activevideo.com <mailto:C.Meerveld@activevideo.com> > wrote:

Hi All,

 

As discussed in the last call ( https://lists.w3.org/Archives/Public/public-web-and-tv/2016Feb/0014.html ) i added some categorised use cases. You could find them here:

 

https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/communication 

 

It contains some generic use cases with more related specific use cases (as example). To me, this is more useful then talk about very specific use cases which could potentially defocus this TF. This section currently only focused on the communication between the application (in a cloud browser) and the client (implementing the rte). Other main sections could have the same structure (i.e. generic use cases with specific examples). I would like to propose to move the specific use cases like 360 or web conferencing to a separate page. I think those are very useful to come up with generic use cases. 

 

Regards,

 

Colin Meerveld