Accessibility errors on search page portlet using OAW tool

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, 7.1.X, 7.2.X, 7.3.X, Master
• Fix Version/s: 7.0.X, 7.1.10 DXP FP26, 7.1.10.7 SP7, 7.1.X, 7.2.10 DXP FP15, 7.2.X, 7.3.10.3 DXP SP3, 7.3.X, 7.4.2 CE GA3, 7.4.13 DXP GA1, Master
• Component/s: Accessibility, Clay, Tag Libraries > Clay Taglibs, Web Search > Search Widgets
• Labels:
  • ee-ts
  • liferay-dxp-71-sp7
  • liferay-dxp-73-sp3
  • liferay-fix-pack-dxp-3-7310
  • liferay-fixpack-dxp-15-7210
  • liferay-fixpack-dxp-26-7110
  • liferay-fixpack-dxp-3-7310
• Branch Version/s:
  7.3.x, 7.2.x, 7.1.x, 7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 3
• Git Pull Request: https://github.com/liferay-frontend/liferay-portal/pull/1152
• Bug Type: Accessibility
• QA Test Name:
  • no-test-needed

Description: Our client is using this tool OAW (https://administracionelectronica.gob.es/comunidades/verPestanaMas.htm?idComunidad=accesibilidad#.YKZABKj7SHv) to verify the accessibility of their portal, in order to be able to run a report with this tool you need to create an account and have a public domain or an HTML page saved as document (this method might leave some external CSS unverified). This tool is owned by the Government of Spain which is used by any public institution to report and verify the validity of their site requested by law. After they used this report they encounter on each page with a Search Portlet added, four different problems: 

1.6 Separation of content and presentation. Generating content from style sheets.
On LPS-57278 we have added in our CSS this style 'content: attr(data-line-number);' see /_generic_portal.scss#L68 this from accessibility point of view is not recommended as this content added from CSS is not accessible for screen readers tools. We need to eliminate this style and redo this functionality by adding this content from JavaScript code.

1.10 Forms and structure. FIELDSET elements that lack a label to identify their content.
Inspect the DOM search for <fieldset, see two fields with no legend inside <FIELDSET class="fieldset "> and <FIELDSET class="input-container"> As requested https://www.w3.org/WAI/tutorials/forms/grouping/ a <fieldset> should always have an <legend> element, as it is serving for description of those input group. 

1.14 Compatibility. Presence of errors in the CSS code that can make it difficult to process it correctly.
The point is complaining about the @charset rule not being on top of the file as this rule should be [1:4671] Unexpected rule '@charset': charset rule in the middle of the file is not allowed! We think this might be related to our way of requesting all the CSS file at once, so we improve the speed of our portal and decrease the requests. This is done by this property theme.css.fast.load portal.properties#L789 which by default is true, if set to false then for each file we will do one request (this is normally used for development environments).

2.5 Device independence. Keyboard focus indicator not visible.
The outline rule: 'outline: 0 !important;' the test is complaining about, it comes from the Clay library in /bootstrap/_reboot.scss#L67, more exact in the bootstrap files, we are not entirely sure if it can be eliminated completely. For this, the focus indicator must be respected and used by default in browsers (without removing it with properties like outline: none) and, in case of modifying it, it will be only to improve its visibility, not to eliminate it.

Steps to reproduce:
1. Add a widget page 
2. Add a Search Portlet to the page
3. Check each point described before

Actual: There are errors present on a simple page with search portlet when client is running a report using OAW tool.

Expected: There are no errors on a simple page with search portlet while using the OAW report tool.

 

---

Reproduction steps might vary depending on the DXP version and OAW errors may be slightly different. See related LPS for more scenarios.