Problem/Motivation

Improve accessibility for screen readers by using aria-description attributes.

Proposed resolution

Add the aria-describedby attribute to associate the form control with its description.

Remaining tasks

Ready to be committed.

User interface changes

None.

API changes

None.

Original report by mgifford

Following on this post here - http://groups.drupal.org/node/4859

I created a patch against D7 to bring this behavior into core. Sure, one could use theme override to do it right, but why not just do that in core.

People want to see the description of what they are going to do before they are going to do it. As I was talking to folks at DrupalCon about this as well, screen readers need the description text before the form that they are going to fill out.

It's a simple fix (and I've made some wee small enhancements to that function as well).
(for legacy issues whose initial post was not the issue summary)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

mgifford’s picture

FileSize
1.57 KB
mgifford’s picture

Status: Needs work » Needs review
Issue tags: +Usability

Hoping previous post's patch gets added to the queue for testing.

Status: Needs review » Needs work

The last submitted patch failed testing.

mgifford’s picture

Any suggestions from anyone on how to track down the single failure out of the 10K tests that were done on this patch:
Test single fields 136 1 0

I looked into modules/profile/profile.test but really suspect this isn't an issue with the patch, but the assumptions in the test.

Just not sure how to resolve it.

Mike

Everett Zufelt’s picture

Status: Needs work » Postponed

I'm not sure that this is necessarily an accessibility advantage. One the one hand it would be nice for this text to be available to a screen-reader user in a apparent way. However, often times screen-reader users tab from form field to form field and would only have this text read if it was marked up as a label for the form field.

Setting to postponed until there is some user testing of screen-reader users / all users, to see if the proposed modifications will really mean accessibility / usability improvements.

kat3_drx’s picture

I can introduce this issue into some usability testing with screen readers and blind users or limited vision users. Starting a new round testing in the near future. Can test with this patch applied, and D7 without to get data.

mgifford’s picture

to add a bit more clarity to this, on this page:
admin/structure/block/manage/search/form/configure

The suggestion was largely to switch the description so that it wouldn't follow the form. Right now the HTML looks like:

<div class="form-item form-type-textfield form-item-title">
<label for="edit-title">Block title </label>
<input id="edit-title" class="form-text" type="text" value="" size="60" name="title" maxlength="64" gtbfieldid="50"/>
<div class="description">
Override the default title for the block. Use
<em><none></em>
to display no title, or leave blank to use the default block title.
</div>
</div>

and I think that this is ultimately what we want it to look like:

<div class="form-item form-type-textfield form-item-title">
<label for="edit-title">Block title </label>
<div class="description">
Override the default title for the block. Use
<em><none></em>
to display no title, or leave blank to use the default block title.
</div>
<input id="edit-title" class="form-text" type="text" value="" size="60" name="title" maxlength="64" gtbfieldid="50"/>
</div>

User testing & feedback from screen reader users is critical!

Everett Zufelt’s picture

Title: Form element description text is in the wrong place » Use aria-describedby to link form elements with form element descriptions
Version: 7.x-dev » 8.x-dev

We won't be making this markup change in D7. I'm not sure if rearranging the order of label - input - description is desirable, but we can use aria-describedby to link input and description inD8.

Everett Zufelt’s picture

Status: Postponed » Active
bowersox’s picture

sub

Everett Zufelt’s picture

Marked #935982: Programmatically associate form element and description with aria-describedby as a duplicate.

Description

Currently the relationship between a form input element and the form element description is not programmatically associated. Using the aria-describedby
property we can programmatically associate form fields with their descriptions. This means that screen-readers who tab through a form will have access
to the form element description without exiting "forms mode".

* for users of technology that supports WAI-ARIA 1.0.

Edit: Users of AT that supports the aria-describedby property of WAI-ARIA 1.0

Liam Morland’s picture

What if we just changed theme_form_element so that the description was wrapped in a label element with a @for pointing to the form control? The HTML standard allows more than one label element per form control. This would solve the issue even for UAs that don't support ARIA.

Liam Morland’s picture

Status: Active » Needs review
FileSize
609 bytes

Here is a patch implementing my suggestion. It is rolled against D8, but that function hasn't changed so it could work with D7 as well.

Minor CSS changes are needed to prevent the description from coming up bold.

Status: Needs review » Needs work

The last submitted patch, description-label.patch, failed testing.

Liam Morland’s picture

I don't understand the error message. Can any one shed some light on this?

Everett Zufelt’s picture

Thanks for the patch.

In the accessibility API on different platforms there is room for a role, name, and description. label normally maps to name and aria-describedby maps to description. I think that this is the most meaningful relationship that we can make, and so we should continue to look at using aria-describedby for the field descriptions.

Role is either determined by the element itself, or the aria role="" on the element.

mgifford’s picture

Status: Needs work » Needs review

#15: description-label.patch queued for re-testing.

mgifford’s picture

Liam, you were wondering about this SimpleTest error, right:
Custom checkboxes option description found. Other form.test 426 FormElementTestCase->testOptions()

as well as the one on the same line for radios. I reran the module and am hoping that this resolves it. Sometimes bots give us grief.

Everett, so we should re-write this patch for us of http://www.w3.org/TR/wai-aria/states_and_properties#aria-describedby

I haven't used this yet, but there are other references here http://www.marcozehe.de/2008/03/23/easy-aria-tip-2-aria-labelledby-and-a...

Status: Needs review » Needs work

The last submitted patch, description-label.patch, failed testing.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
1.18 KB

@#20 Yes, that is the error I am confused about.

@#18 Attached is a patch that adds @aria-describedby to the form control and a corresponding @id to the description. It only generates the description div if there is a description and the element has an @id. Previously, it did not check for the existence of @id. Perhaps someone who knows more about the form API will know if there are times when there is no @id, but there is a description.

Everett Zufelt’s picture

Status: Needs review » Needs work

I took a look at the most recent patch.

Initially I thought that this looked good. After a bit more thought I pondered what happens when we have compound elements, like the Date element. With date elements, AFAIK, the element ID and ari-describedby property would be applied to the date dive itself, and not to any of the form controls that make up the date control.

I think that we will have to apply aria-describedby in the theming functions for each element specifically, so that we can best handle these edge case scenarios.

Someone more familar with form API can correct me if I am wrong on this.

Liam Morland’s picture

For a compound element, such as date, the components, such as month and year, should be wrapped in a fieldset. The fieldset should have an aria-describedby attribute pointing to the description. I don't think it would be correct to have each component also point to that description since the description describes the entire date, not just the month or year.

Everett Zufelt’s picture

@Liam

Agreed, compound elements should be wrapped in a fieldset, see: #504962: Provide a compound form element with accessible labels

We will have to do testing to see how assistive tech (screen-readers, treat aria-describedby on fieldsets. I agree that aria-describedby should be on the fieldset, but if that is giving us no benefit with screen-readers then we might need to re-think.

Liam Morland’s picture

Is there something I can do to help with this? The issue you mention appears to be stalled.

Everett Zufelt’s picture

Yes, it didn't make it into 7, so it was stalled for 8.

As I see it we need to do two things.

1. Fix that issue, I see you have posted a comment there.
2. Test to see how screen-readers treat aria-describedby on fieldsets. This doesn't have to be tested if we can find others who have already tested, or who are willing to test. I'll put out a tweet about it.

Everett Zufelt’s picture

I did some testing of aria-describedby on fieldsets

1. JAWS 11 / FF 3.6
When tabbing to the first element in a fieldset (in forms mode) the legend and text in the aria-describedby reference are spoken. Noting happens on subsequent controls in the fieldset, or when navigating to controls in the virtual buffer.

2. NVDA 2010.1 / FF 3.6
Same as for JAWS

3. VoiceOver and Safari 5
Nothing is spoken when navigating to the controls in any way. However, when navigating to the fieldset (in object navigation mode) the aria-described by text is spoken as a description of the group. The user must then interact with the group to fin the controls.

From the above I am comfortable adding aria-describedby to fieldsets. It will provide an enhancement for some users.

<fieldset aria-describedby="myDesc">
<legend>Some legend</legend>
... compound element controls ...
<p id="myDesc>Some description text</p>
</fieldset>
mgifford’s picture

Patch applies nicely but the output doesn't look at all like Everett's HTML. I just wanted to report that it's been tested & needs to be written to focus the information on the fieldset.

Liam, was great hanging out with you & Everett at http://www.accessconf.ca

Liam Morland’s picture

It was great to meet both of you.

Everett's HTML is a test case for using aria-describedby to associate a description with a fieldset. That will be used when compound elements are wrapped in a fieldset. That part of the problem is being addressed in #504962: Provide a compound form element with accessible labels .

The patch in this issue does the first part of the problem, which is using aria-describedby for descriptions of elements in general.

mgifford’s picture

I'd lost track of this issue so was looking at what to test for.

In looking at this code however:

  if (!empty($element['#id']) && !empty($element['#description'])) {
    $attributes = array('class' => 'description', 'id' => $element['#id'] . '--description');
    $output .= '<div' . drupal_attributes($attributes) . '>' . $element['#description'] . "</div>\n";
   }
 

Occurred to me that it is entirely possible that the description has an ID already. In which case we should use that rather than replace it. I think that should be possible but haven't checked.

Can this patch be properly tested without the grouped fieldsets issue in #504962?

Everett Zufelt’s picture

Status: Needs work » Needs review

@mgifford

It doesn't appear to me that the description currently has an id. Can you test to see that aria-describedby is being properly applid to:
1. form elements (input, select, etc) with a description.
2. The div wrapping compound elements (date, checkboxes, radios).
3. Not being applied to any form elements, or compound elements, without a description

@liam

I think that we can proceed with the patch without the fieldset issue being committed. This will not provide any benefit to compound elements at this time, but will apply and work nicely when the fieldset issue is fixed.

mgifford’s picture

It's not a question about whether or not a description does presently have an ID assigned to it. This would override it so that a form description couldn't have an id assigned for it.

I think we should check if an ID is assigned before forcing in a new one.

Liam Morland’s picture

The D8 code has no provision for applying an @id to the description div element. It is hard-coded that the div only gets a @class, so we're safe to add our own.

mgifford’s picture

Excellent. Thanks for checking Liam.

Looking at the source & searching for --description it is easy to see how these are nicely paired to descriptions.

Date:

<div class="form-item form-type-textfield form-item-date"> 
  <label for="edit-date">Authored on </label> 
 <input aria-describedby="edit-date--description" type="text" id="edit-date" name="date" value="" size="60" maxlength="25" class="form-text" /> 
<div class="description" id="edit-date--description">Format: <em class="placeholder">2011-06-07 00:00:06 -0400</em>. The date format is YYYY-MM-DD and <em class="placeholder">-0400</em> is the time zone offset from UTC. Leave blank to use the time of form submission.</div> 
</div> 

Radio buttons:

<fieldset class="comment-node-settings-form collapsible collapsed form-wrapper" id="edit-comment-settings"><legend><span class="fieldset-legend">Comment settings</span></legend><div class="fieldset-wrapper"><div class="form-item form-type-radios form-item-comment"> 
  <label class="element-invisible" for="edit-comment">Comments </label> 
 <div id="edit-comment" class="form-radios"><div class="form-item form-type-radio form-item-comment"> 
 <input aria-describedby="edit-comment-2--description" type="radio" id="edit-comment-2" name="comment" value="2" checked="checked" class="form-radio" />  <label class="option" for="edit-comment-2">Open </label> 
 
<div class="description" id="edit-comment-2--description">Users with the "Post comments" permission can post comments.</div> 
</div> 
<div class="form-item form-type-radio form-item-comment"> 
 <input aria-describedby="edit-comment-1--description" type="radio" id="edit-comment-1" name="comment" value="1" class="form-radio" />  <label class="option" for="edit-comment-1">Closed </label> 
 
<div class="description" id="edit-comment-1--description">Users cannot post comments.</div> 
</div> 
</div> 
</div> 
</div></fieldset>

Weight:

<div class="form-item form-type-select form-item-menu-weight"> 
  <label for="edit-menu-weight">Weight </label> 
 <select aria-describedby="edit-menu-weight--description" id="edit-menu-weight" name="menu[weight]" class="form-select"><option value="-50">-50</option><option value="-49">-49</option><option value="-48">-48</option><option value="-47">-47</option><option value="-46">-46</option><option value="-45">-45</option><option value="-44">-44</option><option value="-43">-43</option><option value="-42">-42</option><option value="-41">-41</option><option value="-40">-40</option><option value="-39">-39</option><option value="-38">-38</option><option value="-37">-37</option><option value="-36">-36</option><option value="-35">-35</option><option value="-34">-34</option><option value="-33">-33</option><option value="-32">-32</option><option value="-31">-31</option><option value="-30">-30</option><option value="-29">-29</option><option value="-28">-28</option><option value="-27">-27</option><option value="-26">-26</option><option value="-25">-25</option><option value="-24">-24</option><option value="-23">-23</option><option value="-22">-22</option><option value="-21">-21</option><option value="-20">-20</option><option value="-19">-19</option><option value="-18">-18</option><option value="-17">-17</option><option value="-16">-16</option><option value="-15">-15</option><option value="-14">-14</option><option value="-13">-13</option><option value="-12">-12</option><option value="-11">-11</option><option value="-10">-10</option><option value="-9">-9</option><option value="-8">-8</option><option value="-7">-7</option><option value="-6">-6</option><option value="-5">-5</option><option value="-4">-4</option><option value="-3">-3</option><option value="-2">-2</option><option value="-1">-1</option><option value="0" selected="selected">0</option><option value="1">1</option><option value="2">2</option><option value="3">3</option><option value="4">4</option><option value="5">5</option><option value="6">6</option><option value="7">7</option><option value="8">8</option><option value="9">9</option><option value="10">10</option><option value="11">11</option><option value="12">12</option><option value="13">13</option><option value="14">14</option><option value="15">15</option><option value="16">16</option><option value="17">17</option><option value="18">18</option><option value="19">19</option><option value="20">20</option><option value="21">21</option><option value="22">22</option><option value="23">23</option><option value="24">24</option><option value="25">25</option><option value="26">26</option><option value="27">27</option><option value="28">28</option><option value="29">29</option><option value="30">30</option><option value="31">31</option><option value="32">32</option><option value="33">33</option><option value="34">34</option><option value="35">35</option><option value="36">36</option><option value="37">37</option><option value="38">38</option><option value="39">39</option><option value="40">40</option><option value="41">41</option><option value="42">42</option><option value="43">43</option><option value="44">44</option><option value="45">45</option><option value="46">46</option><option value="47">47</option><option value="48">48</option><option value="49">49</option><option value="50">50</option></select> 
<div class="description" id="edit-menu-weight--description">Menu links with smaller weights are displayed before links with larger weights.</div> 
</div> 

But it only shows up once for the Image upload:

<div class="field-type-image field-name-field-image field-widget-image-image form-wrapper" id="edit-field-image"><div id="edit-field-image-und-0-ajax-wrapper"><div class="form-item form-type-managed-file form-item-field-image-und-0"> 
  <label for="edit-field-image-und-0">Image </label> 
 <div class="image-widget form-managed-file clearfix"><div class="image-widget-data"><input type="file" id="edit-field-image-und-0-upload" name="files[field_image_und_0]" size="22" class="form-file" /><input type="submit" id="edit-field-image-und-0-upload-button" name="field_image_und_0_upload_button" value="Upload" class="form-submit" /><input type="hidden" name="field_image[und][0][fid]" value="0" /> 
<input type="hidden" name="field_image[und][0][display]" value="1" /> 
</div></div> 
<div class="description" id="edit-field-image-und-0--description">Upload an image to go with this article.<br />Files must be less than <strong>64 MB</strong>png gif jpg jpeg</strong>.</div> 
</div> 

I do think though that this last one with the images can be treated in a separate issue. The rest seems to work very well.

Liam Morland’s picture

Image upload clearly needs work: The label @for doesn't point to anything. This is another case where the multiple input elements should be wrapped in a fieldset, the label should be the legend, and the fieldset should have the @aria-describedby pointing to the description. I agree that fixing this should be a separate issue.

Everett Zufelt’s picture

Status: Needs review » Needs work

I think we will have to find a different approach, other than modifying drupal_render()

The goal is that D8 will be html5, but that contributed themes can be xhtml 1.0 by overriding / altering content. AFAIK, there is no way for a theme to alter drupal_render(), so they would not be able to remove the aria-describedby attributes, therefore causing them to not validate under xhtml 1.0

I'll ping @jacine to get her input.

Liam Morland’s picture

What if drupal_attributes() was patched so that it would remove any aria-* attributes if the installation or theme was configured to not display them?

Everett Zufelt’s picture

@Liam

Interesting suggestion. Can you integrate it into the discussion at #966396: Decide how to include WAI-ARIA landmark roles please.

If we had a setting for ARIA (or html5 even) on / off, then when off we could remove all role and aria-* attributes.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
1.14 KB

Here is a patch that adds @aria-describedby in form_builder() instead of drupal_render().

Jacine’s picture

Component: base system » markup
Everett Zufelt’s picture

Assigned: mgifford » Unassigned

This looks good to me. I think we need to make sure that we file a follow-up once this is committed for the grouped elements.

Adding aria-describedby to #attributes means that if for some reason a theme wishes to remove this they can do so in a preprocess function.

Everett Zufelt’s picture

Status: Needs review » Needs work

I took one more look through.

I think we can remove the condition !empty($element['#id']) from form_builder(). Earlier in the function, near the beginning, there is already a test, and if it returns false an #id is generated for $element.

As for theme_form_element() I think we should leave the test, as it is possible, however unlikely, that #id will be unset. We might also want to still print #description even if there isn't an #id on $element.

I'm also wondering if it might be worthwhile to add the URL to WAI-ARIA description of aria-describedby to the comment in form_builder(). This might be unnecessary, but could be helpful for those who are unfamiliar with WAI-ARIA.

I think that if we do this we can mark this RTBC.

Everett Zufelt’s picture

Just noticed that in form_builder() the patch is actually acting on $element[$key][*]. This is within a foreach and $key is the child of the current element.

This works as expected, but I think that we are actually iterating over the elements more than once, once as children, and again as parents. I think we should move the logic out of the foreach so that we are performing this logic once per form element.

Everett Zufelt’s picture

Issue tags: +html5

Tagging.

Everett Zufelt’s picture

Status: Needs work » Needs review
FileSize
1.17 KB

Made changes from #43 - #44, left out the URL to WAI-ARIA aria-describedby.

Everett Zufelt’s picture

Regarding compound elements (image, file, date, radios, checkboxes), these are not the only elements that concern me. Currently the patch will also apply aria-describedby to table tableselect, etc. I'm not sure how to best handle this.

I suppose that for compound elements hopefully our solution for wrapping those (fieldset or otherwise) will carry semantics that will still allow the description to be mapped to accessibility APIs by UAs. For elements where this is not the case the attribute will still be in place, but will likely provide little to no benefit to AT.

Jacine’s picture

Status: Needs review » Needs work
+++ b/includes/form.incundefined
@@ -1737,6 +1737,12 @@ function form_builder($form_id, &$element, &$form_state) {
+  // add the aria-describedby attribute to associate the form control with its
+  // description

Can we please capitalize "add" and add a period at the end of the sentence. Otherwise, from my limited testing, it looks good.

mgifford’s picture

Status: Needs work » Needs review

#46: aria-describedby_1.patch queued for re-testing.

Jacine’s picture

Status: Needs review » Needs work

The patch applies and passes testing, but it still needs work per #48.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
1.17 KB

Attached patch implements notes in #48.

Everett Zufelt’s picture

Status: Needs review » Needs work

I still think we need to figure out how to deal with weird / complex elements, like tableselect. Should these elements receive aria-describedby, or should we create an array of acceptable #types that should receive aria-describedby and test in form_builder()?

Pro: elements that don't need aria-describedby don't get it.

Con: not very extensible to new / contrib elements.

Everett Zufelt’s picture

mgifford’s picture

Patch applies nicely. It's easy to test it by creating content with core, say /node/add/forum

Everett, any ideas on how to deal with the weird & complex?

Everett Zufelt’s picture

Nope.

On one hand we don't wnt to use a closed list of element types, because then the solution is not extensible. On the other hand a closed list ensures tat aria-describedby only gets applied where appropriate (e.g input, textarea, select), and not table, tableselect, etc, other compound elements.

mgifford’s picture

Can we just exclude the weird/complex from this solution & build something that we know works in the use cases we understand?

I'd like to have some way we can move ahead on this.

Liam Morland’s picture

Mike, I agree. I think this patch should be committed so people will see how it works in the real world. That might help us to figure out a way to deal with complex elements.

mgifford’s picture

Status: Needs work » Needs review
Issue tags: -Needs issue summary update, -Accessibility, -html5

#51: aria-describedby.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs issue summary update, +Accessibility, +html5

The last submitted patch, aria-describedby.patch, failed testing.

Liam Morland’s picture

Status: Needs work » Needs review
FileSize
1.19 KB

Updated patch rolled against latest D8.

mgifford’s picture

Status: Needs review » Needs work

Ok, I applied this and git accepted it with no problems. However, when I looked at the output of the fields in admin/config/development/performance that had description elements, I didn't see id's on the div tags or links to those ID's. Am I missing something? I cleared the cache.

Liam Morland’s picture

@id and @aria-describedby are showing up for me in admin/config/development/performance.

mgifford’s picture

Status: Needs work » Needs review

#60: aria-describedby.patch queued for re-testing.

tlattimore’s picture

I can confirm that the patch applies cleanly and that the id and aria-describeby are showing up for me on admin/config/development/performance.

Ron Williams’s picture

Status: Needs review » Reviewed & tested by the community

Reviewed with eddib as part of the DrupalCon core sprint to test. Works as described.

chx’s picture

So why this is not good for D7? it seems to me the only relevant markup change is adding an id attribute to the <div class=" description">.

mgifford’s picture

@chx take a look at #35 for examples of the output.

The point of this is to tie in a description to a form element so that it is given more context. I put up a link to more info about aria-describedby in #20 above.

It's not about markup, it's about adding additional semantics. It adds meaning to the forms where there is none at the moment.

Hope this helps to clarify. And yes, would be great to backport it to D7.

webchick’s picture

Sounds like the aria-describedby attribute is not valid XHTML, so this is probably not a candidate for D7. Or am I wrong? Everett seems to be saying as much in #37.

mgifford’s picture

Looking to hear back from @Everett, but it seems to be fine with xHTML HERE - http://www.w3.org/TR/WCAG20-TECHS/ARIA1.html

Could well be that the docs are out of date though.

Liam Morland’s picture

ARIA is not part of normal (X)HTML, but there are doctypes you can use which include it. I had understood that the idea was to include ARIA in D8 and have the Accessible Helper Module take care of it for D7, though that seems to have stalled.

mgifford’s picture

Yes, the Accessible Helper module needs more love. I put an intern on it this summer for a bit, but it's not really playing the role I'd envisioned.

Ultimately accessibility doesn't tend to get the resources that are required to make it work properly.. Lots of folks just assume it's there and that it will just work somehow.

catch’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Thanks folks. Committed/pushed to 8.x, moving back to 7.x for backport - not entirely clear if it can be or not.

Liam Morland’s picture

It can be backported. The question is, Do we want to introduce ARIA markup into D7 core? Or should we be making a version of the Accessible Fix module which includes just those fixes which we have working now, such as this one?

bowersox’s picture

I believe that we DO have ARIA markup in core that is added by Javascript on the browser side (e.g. http://drupal.org/node/521904). But we DO NOT have ARIA markup in D7 core that is directly included in theme files/functions and HTML output on the server side. It was decided that we did not want to break HTML validity for D7.

For D8 we agreed to change our approach and allow ARIA markup directly into core theme files/functions: http://drupal.org/node/963760

So the patch above should not go into D7 core because it applies the ARIA markup on the server side. It would be possible (although tedious) to write a new patch that introduces a D7-only Javascript solution for adding aria-describedby on the browser side.

I would love to be corrected about this.

Everett Zufelt’s picture

Version: 7.x-dev » 8.x-dev
Status: Patch (to be ported) » Fixed

@Webchick is correct. aria-describedby is not valid xhtml 1.0. A decision was made in the d7 dev cycle to not invalidate markup, so I think we should stick with that. If someone feels strongly that this is the wrong decision please open a new issue as a task to discuss changing the markup validity policy.

Status: Fixed » Closed (fixed)
Issue tags: -Needs issue summary update, -Accessibility, -html5

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Cleanup issue with proper summary.