EN-301-549-Design-Principles.md

@@ -6,7 +6,7 @@ From the beginning of the work on EN 301 549, three very fundamental principles
 
 >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. ).
+>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 it has 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.
 
@@ -18,6 +18,6 @@ From the beginning of the work on EN 301 549, three very fundamental principles
 
 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
+4. It is **not permissible to have a requirement ("shall") or a recommendation ("should") 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