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

Hi John,

Thank you for your feedback, this is very useful! I am quite familiar with the Web Accessibility Initiative ( https://www.w3.org/WAI/ ). You raise some fundamental questions. Just as a reference for those who are less familiar with the technology behind accessibility, here are the traditional actors:

operating system: provide accessibility api (proprietary)
assistive technology: uses this api to translate the output to something meaningful. e.g. braille, zooming in to a particular section and input such-as gestures to key strokes
user agent: connect to the api (like translating the semantics from the application and UA configurations such-as specified in UAAG  https://www.w3.org/TR/UAAG10 )
application: is authored (in case of web standards) using WCAG ( https://www.w3.org/TR/WCAG20/ ) and ARIA ( https://www.w3.org/WAI/intro/aria.php )

The cloud browser is less strict in who the actors are .We should need to identify this more in depth in the cloud browser architecture ( https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/Architecture ). To me the OS is not defined in a cloud environment and therefore it is less obvious how the assistive technology could connect to it (UAAG 1.0 guidelines 6 and 7 are related). UAAG defines the User agent as follow:

“Any software that retrieves and renders Web content for users”

In the cloud browser - especially in double stream approach - this would be both the cloud browser as-well as the runtime environment (because the video play-out could be locally). To make a cloud browser accessible there are a couple of solutions:

1. Let the assistive technology connect to the rte which delegate all the information from the cloud browser to it.
2. Let the assistive technology directly connect to the cloud environment which (delegate the information to the cloud browser) through another device such as a smartphone
3. Build in (assistive) technology to make the application accessible

Probably a mix of those solutions should fill the gap. The first solution is close to the traditional environment but has some limitations. As far as i know there is no stb who has implement an accessibility api ( https://www.w3.org/TR/html-aapi/ ) though there are strong regulations regarding accessibility on so-called cpe ( https://en.wikipedia.org/wiki/Customer-premises_equipment ). Most of them implemented a proprietary way to comply with those regulations. In addition most assistive technology are attached to a pc or smart device and make less sense to connect to the cpe directly. Therefore solution two could be an option but i am not sure if this TF should focus on that part (in essence it is on the same level as assistive technology to OS and visa versa). This is also true for the third option where the cloud environment should add those functionality.

That said we should make sure that the technology we are defining could be accessible.  A simplistic view would be to define assistive technology as a “service" explained in ( https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF/UseCases/communication ) and add “specific” use cases so that we have a clear picture what it means to make a cloud browser, accessible.

John, it would be very helpful if you could help with those use cases.

Thanks,

Colin

On 24 Feb 2016, at 17:55, John Foliot <john.foliot@deque.com<mailto:john.foliot@deque.com>> wrote:

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)

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/ 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/#access-to-interactive-controls-menus

•        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/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-navigation

•        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
john.foliot@deque.com<mailto: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<mailto:ronen@tversity.com>>
Cc: public-web-and-tv@w3.org<mailto: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