See related #242 "Add definition: continuous real-time conversation (from TR 103 708)"
Add the following definition from TR 103 708
continuous real-time conversation: type of organization in conversation and discourse where one participant's contribution is made available to other participants while it is being made
Intent from the TR was to define contexts like full duplex voice, video for sign language, real-time-text, etc. but differentiate from broadcast (one-to-many), turn-based comms, or turn-like half-duplex convos like sending audio recordings back and forth, even when those are streamed.
Based on some of the ideas introduced in Issue #234, the following proposal attempts to:
In each of the 6.2.1.1.x tests described in Issue #234 there is a multi-step procedure that involves the typing and receiving of characters as being a test that the "RTT communication" referred to in the requirements is achieved. To ensure that what is tested corresponds to what is required, this multi-step procedure is summarised in a new term "reliable two-way RTT communication". This term defines a concept that is only relevant in the context of the requirements and tests of EN 301 549 and not intended to have any significance beyond that very specific usage. The definition is as follows:
reliable two-way RTT communication: text typed continuously for 10 seconds without the use of the return or send key appears at the other end of a connection whichever end originated the connection
Where ICT provides functionality that allows continuous two-way voice communication with one or more people,
the ICT should provide functionality that allows two-way RTT communication with those same people, except where this would require design changes to add input or output hardware to the ICT.
Where ICT is an electronic communication service,
and it supports two-way voice communication with one or more electronic communication services,
the ICT shall support reliable two-way RTT communication with the other services.
Where ICT is an electronic communications service supporting two-way voice communications between ICT within the service,
the ICT shall support reliable two-way RTT communication between the same ICT in the service.
Where ICT is an electronic communication service, and it supports two-way voice communication with one or more electronic communication services,
the ICT shall support reliable two-way RTT communication with a user who is roaming and using a different service.
Where ICT is an electronic communication service, and it supports two-way voice communication with emergency services,
the ICT shall support reliable two-way RTT communication with emergency services.
Where ICT supports two-way voice communication with other ICT within a service or directly between ICT over a network,
the ICT shall support reliable two-way RTT communication with the other ICT, except where this would require design changes to add input or output hardware to the ICT.
NOTE 1: There is no requirement to add: a hardware display, a hardware keyboard, or hardware to support the ability to connect to a display or keyboard, wired or wirelessly, if this hardware would not normally be provided.
NOTE 2: This requirement includes those products that do not have physical display or text entry capabilities but have the capability to connect to ICT that do have such capabilities as long as it does not require design changes to add input or output hardware to the ICT. It also includes intermediate ICT between the endpoints of the communication.
NOTE 3: This requirement applies to ICT that supports all types of real-time two-way voice communication between ICT, including those between people each using ICT, and a person using ICT on one end and ICT alone on the other end. For example, it would apply to a two-way voice conversation option on a user’s ICT that connects directly over IP to a bank, or doctor, or person, or organization even if no remuneration or use of user data etc is provided by user in exchange for using the voice option.
(this is the old 6.2.1.2 and there are no proposed changes to its content)
Where ICT provides a means for two-way voice communication and for users to communicate by RTT,
it shall allow concurrent voice and text through a single user connection.
NOTE 1: With many-party communication, as in a conference system, it is allowed (but not required or necessarily recommended) that RTT be handled in a single display field and that "turn-taking" be necessary to avoid confusion (in the same way that turn-taking is required for those presenting/talking with voice).
NOTE 2: With many-party communication, best practice is for hand-raising for voice users and RTT users to be handled in the same way, so that voice and RTT users are in the same queue.
NOTE 3: With a many-party conference system that has chat as one of its features - the RTT (like the voice) would typically be separate from the chat so that RTT use does not interfere with chat (i.e. people can be messaging in the chat field while the person is presenting/talking with RTT - in the same manner that people message using the chat feature while people are talking with voice). RTT users would then use RTT for presenting and use the Chat feature to message while others are presenting (via Voice or RTT).
NOTE 4: The availability of voice and RTT running concurrently (and separately from chat) can also allow the RTT field to support text captioning when someone is speaking (and it is therefore not being used for RTT since it is not the RTT user's turn to speak).
Unlike Issue #234, the corresponding tests that the requirement has been met will not be by means of attempting to set up a connection and test that RTT communication has been achieved, but by the availability of evidence that successful testing has "has been achieved in any manner" (to quote the language used in one of the Issue #234 C.6.2.3.x pre-conditions).
A test of 6.2.1.2, that is compatible with how all the other tests in EN 301 549 have been constructed would read:
Type of assessment | Declaration |
---|---|
Pre-conditions | 1. The ICT under test is an electronic communication service that supports two-way voice communication with one or more electronic communication services |
Procedure | 1. Check if there is documented evidence that reliable two-way RTT communication with another service has been achieved, whichever service originates the communication. |
Result | Pass: Check 1 is true Fail: Check 1 is false Test is not applicable, or test is not valid if pre-condition 1 is not met. |
All the other tests can follow the identical pattern of mapping the requirement pre-conditions into the test pre-conditions and the body of the requirement as the single step of the test procedure.
"Braille" only needs capitalization when referring to the proper noun, as in "Louis Braille created Braille, a tactile alphabet." Adjective uses like "braille device" follow standard capitalization rules, so all instances in the EN should be lowercased unless they are in a title or begin a sentence.
This seems like a good proposal to me.
Requirement 11.5.2.3 of current EN mentions two different sets of services that can be used in order to meet clauses 11.5.2.5 to 11.5.2.17 of the interoperability with assistive technologies, namely:
Maybe it is a good idea that NOTE 2 proposed by @martineznorm acknowledges and helps to differentiate both types of services. Both 1) and 2) services are documented platform services, and therefore both sets belong to the platform API. The difference is that only 1) services belong to the platform documented accessibility (i.e., the accessibility API).
Hence, NOTE 2 could be rewritten as
NOTE 2 "Documented platform accessibility services" are a subset of the platform's application programming interface (API) that allows application developers to create software that is compatible with assistive technologies. Depending on the platform, these services may be referred to by different names, such as accessibility services or accessibility API. Alternatively, compatibility with assistive technologies may be achieved by using "other documented services" that are not part of the accessibility API, but are part of the platform's user interface services.
At the 20th March STF614 meeting it was agreed that the above proposed changes to the content of table B.2 should be incorporated into an updated draft of EN 301 549.
It was noted that further changes to table B.2 may still be needed.
At the 20th March STF614 meeting it was agreed that the two "shall"s in 11.5.2.3 should become two "should"s, and that the amended version should be incorporated into an updated draft of EN 301 549.
The above comments related to the addition of a note to 11.5.2.1 will be taken into account in ongoing work on identifying potential changes to other 11.5.2.x requirements.
I agree with the proposal to change clause 11.5.2.3 "Use of accessibility services" from a "shall" into a "should", since it seems to resolve issues I have brought before STF614 in issue #60 and in the attached discussion document about the testability of clauses 11.5.2.X.
@martineznorm , do you agree that we include your proposal in the work @rodriguezasc and I are doing to improve requirements 11.5.2.x since we already cover 11.5.2.1 there also?
Could you be a bit more specific why do you think this requirement is outside of the scope of EN 301 549? For me, it is the role of this standard to define some common agreed upon rules in the frame of the WAD and EAA. The standard is there to support the application of these directives. This point can indeed be discussed in the frame of the WADEX group, but if we reach a consensus, we should write it down somewhere and to my mind, the EN may be a good place to do it.
Hi,
Thanks, @vagnera , for sharing the issue with WADEX! I am going to post the current text both to the GitLab issue and the WADEX group chat.
I analysed a bit about why we in Estonia have understood that "the feedback mechanism", as explained in 2018/1523, is not the same as "support services", as explained in EN 301 549 V.3.2.1 clause 12.2:
By the way, our blank for public sector bodies to make their own accessibility statement includes a sentence: "We will usually reply to you in [response time]." Thus, we indicate to public sector bodies that there should be a reasonable deadline by which a citizen is going to get a reply (I haven't made explicit statistics regarding it, but it seems that the most commonly used sentence is "we will usually reply within 5 working days."). That means that we treat the feedback mechanism as almost like the support service (instead of responding "now," as said by Mark, it is allowed to respond in a longer timeframe).
My proposal is to clarify clause 12.2 in EN 301 549, if we intend to treat the feedback mechanism as a support service. For me personally, it seems that 2018/1523 and clause 12.2 don't speak about exactly the same thing (i.e., it is not correct to put the equality sign between the two). One option to overcome that obstacle is to make the meaning of "support service" in the EN wider (i.e., support services are not only these kinds of customer support that respond now, but they are also allowed to respond in a longer timeframe, etc.).
After reading article 13 and annex V of Directive 2019/882, I think that service providers are required to provide information on the accessibility of their service, and that information would then become "product documentation" for the service and clause 12.1 of EN 301 549 applies. That documentation shall "list and explain how to use the accessibility and compatibility features" (12.1) and it shall be provided in accessible formats (12.2).
I personally don't think that we need to change EN 301 549 for this.
I agree with @pluke comments. In my opinion, the WAD-required accessibility feedback is a support service, and clause 12.2 applies. And I don't see any reason for any service claiming that their web (or mobile app) conforms to WAD to not provide an accessible "accessibility feedback" in the terms of clauses 12.2.1, 12.2.2, 12.2.3 and 12.2.4.
But I also think that this discussion is outside of scope for EN 301 549, as the requirement for accessibility feedback is part of the WAD regulation. It seems a very good issue to agree on for WADEX.
As the original author of annex B, I do know that it contains many mistakes.
I agree with all the changes proposed in this issue .
I agree with the proposal. All the 13 requirements that are related to 11.5.2.3 already mandate the use of accessibility services, so I don't think that changing 11.5.2.3 into a should would have any negative impact.
But we should improve the explanation about the meaning of accessibility services. The full section 11.5.2 is about accessibility API for software developers, but when creating the first version we decided to call that "accessibility services" instead of "accessibility API". That can create some confusion, as explained in the presentation on 11.5.2.x. I propose the following modification to NOTE 2 of 11.5.2.1
NOTE 2 These services are an Application Programming Interface (API) that enable the application developers to build software that is compatible with assistive products. In some platforms these services may be called accessibility services, but in some other platforms these services may be provided as part of the user interface services.
As described in the attached discussion document about the testability of clauses 11.5.2.X clauses, clause 11.5.2.3 has been causing serious problems in testing conformance to EN 301 549 as this one requirement requires that 13 other requirements are met! In a meeting of STF614 there appeared to be general consensus that this problem can be completely solved by converting 11.5.2.3 into a "should" requirement.
This solution preserves the general guidance that full use should be made of all accessibility services, but only requires the use of specifically named accessibility services. The overall testability problem caused by 11.5.2.3 will have been removed, whilst preserving the important guidance that this clause contains.
As I wrote in response to Issue #238, I think that the feedback mechanism related to the accessibility statement should be considered as a support service, and therefore within the scope of the separate Harmonised Standard on "the accessibility of support services", as it would seem somewhat strange for EN 301 549 to specify detail of how such a service that is providing information/support to users of a service should operate in a different way to all other types of services that are generally understood to be support services.
If this is the case, then EN 301 549 will probably need to explicitly name the feedback mechanism as a support service in 12.2.1, which would then point to the other Harmonised Standard for requirements that apply to all such services, including that related to the feedback mechanism.
12.2.2 already addresses "Information on accessibility and compatibility features" related to products. On the services side, what is ultimately needed is an equivalent way to express what is needed.
I agree with all of these proposed changes.
This topic is closely linked to the existing topic #229 (and I have added it as a linked item).
My initial thoughts on this subject are that the issue that you raise would appear to be either within the scope of the Harmonised Standards for "requirements on the accessibility of non-digital information related to products and services" or, more likely, the one on "the accessibility of support services".
Whether the provision of information about whether a service is accessible, and how this service operates, falls under the topic of a "support service" is really the point of issue #229. My thoughts are that, when this classification is clear, EN 301 549 will point to whichever of the two Harmonised Standards specifies how users can obtain the relevant information.
In the mandate 587 annex there is a request. "There is no CE marking for services, so it is difficult for a consumer to find information about accessible services. In Directive 2019/882, Annex V includes requirements on information on services. In the development of new or revised harmonised standards, with requirements on services, provisions must be amended with specifications on how consumers can get information on the accessibility of the service and how to make complaints. This information must be published and accessible, according to Annex I of Directive 2019/882." Is that something that is considered?