EN-301-549-Design-Principles.md

+# The EN 301 549 design principles
+
+From the beginning of the work on EN 301 549, three very fundamental principles were established:
+
+1. **In EN 301 549, requirements are written to apply to specific features and functionalities that ICT products may or may not have** (e.g. screens, keyboards, audible alerts
+
+>Requirements deliberately avoid referring to any specific class of product or service, as the boundaries that define what products or services belong within these product classes are usually insufficiently precise. Also, the types of functionalities that members of this product or service class may have can increase, or less commonly decrease, over time. Prior to the introduction of Smart TVs and the iPhone in 2007, the assumption would have been that requirements related to internet connectivity, apps, and wireless connection to other devices, were to either TVs or phones.
+
+>This detachment of product features from product types has made it comparatively easy to update the EN as the scope of applicability has changed (from public procurement to Web and mobile apps). It has also meant that we have never been necessary to resort to trying to define product/service types that are referred to in the relevant legislation. ).
+
+>Not having requirements related to specific product and service types, and not having to create our own definitions for those product and service types, should prove very beneficial as the scope of applicability expands significantly to align with the EAA.
+
+2. As stated in EN 301 549 Clause 14 "Conformance":
+
+>>" **All clauses except those in clause 12 are self-scoping**. This means they are introduced with the phrase 'Where ICT \<pre condition\>'. A requirement is met when the pre-condition is true and the corresponding test (in Annex C) is passed."
+
+>This principle that was established from day one of the development of the first version of EN 301 549. This allows every requirement in the EN to be stand-alone, without relying on any external dependencies. It is worth noting that we may need to revisit the scoping text of some of our requirements to take into account issues that arise as we consider types of ICT we did not previously explicitly consider.
+
+3. Unlike other standards. such as the US Section 508, **EN 301 549 does not rely on the user of the standard having to check "exceptions" included in the document before deciding whether a requirement should be applied or not**. Any of the few exceptions that apply to individual requirements are written into those requirements.  This approach preserves the standalone nature of the requirements and reduces the danger that people will try to apply requirements in situations where an exception elsewhere in the standard says that they should not be required. Where we do incorporate exceptions into requirements, they are there for a specific reason, and not just as a blanket escape clause to avoid being required to meet the legitimate accessibility need just because it might be difficult to do so.
+
+2. It is **not permissible to have a "shall" in a note, or to introduce an exception in the form of a note,** as notes should not modify the meaning or scope of requirement in any way. Notes should be purely informative and help users by, for example, giving supportive information. In particular
+
+>The above principles have made EN 301 549 relatively easy to adapt and extend as the scope of the EN has changed. Proposals for new requirements or modification of existing requirements should not deviate from these principles. Creative approaches will be needed to resolve the issue of concern whilst staying within the constraints of these principles. In the words of Igor Stravinsky "The more constraints one imposes, the more one frees oneself. And the arbitrariness of the constraint serves only to obtain precision of execution." The above constraints are in no way arbitrary!
\ No newline at end of file