When I tab to or hover over the home icon in the breadcrumbs, I see no visual cue to indicate that it is a hyperlink and has focus.

The other elements in the breadcrumbs change color and display an underline when in focus. I would expect the home icon to do the same.

Link text (#08d on white) fails to meet WCAG 2.0 contrast requirements for compliance at Level AA. The current combination has a contrast ratio of 3.7731, whereas Level AA compliance requires at least 4.5. To meet the requirement with minimal impact, change link color to #0074bb.

Links in the main content are distinguishable from surrounding text by color alone. This is not accessible to people who are unable to perceive color differences, and is a violation of WCAG 2.0 at Level A (Success Criterion 1.3.3).

On the Accessibility site, you added (at our request) a 1px solid border-bottom as a solution that is more subtle than text-decoration: underline. However, this is awfully subtle, barely visible for some people and we've received some complaints about it.

Preferred solution:

1. Push an easier-to-see solution to the Accessibility site (either a darker border-bottom color, or 2px instead of 1px or both).
2. Get some sort of solution - either subtle or less subtle - pushed universally

Clicking the "Quick Links" button text opens the menu but clicking the little svg arrow does not.

Oddly clicking the svg "x" closes the quick links menu.

When a keyboard user tabs through the banner (audience-based navigation, search icon, and Quick Links button), the only visible indication that an item has focus is a change of color. This is not accessible to people who are unable to perceive color differences.

There needs to be some additional indication of keyboard focus that's not dependent on color perception. For example, underlining the item that has focus would be effective.

We have updated our child theme to point to the UW 2104 theme. I'm running this on my development vagrant box. In the wp-config.php file I have the setting: define('WP_DEBUG', TRUE);

This message is created by navigating to any page in our site

PHP Notice: Trying to get property of non-object in /data/www/ap/cms/wp-content/themes/uw-boundless/inc/template-functions.php on line 196, referer: http://192.168.50.4/ahr/
PHP Stack trace:, referer: http://192.168.50.4/ahr/
PHP 1. {main}() /data/www/ap/index.php:0, referer: http://192.168.50.4/ahr/
PHP 2. require() /data/www/ap/index.php:17, referer: http://192.168.50.4/ahr/
PHP 3. require_once() /data/www/ap/cms/wp-blog-header.php:16, referer: http://192.168.50.4/ahr/
PHP 4. include() /data/www/ap/cms/wp-includes/template-loader.php:89, referer: http://192.168.50.4/ahr/
PHP 5. get_template_part() /data/www/ap/cms/wp-content/themes/uw-boundless/404.php:11, referer: http://192.168.50.4/ahr/
PHP 6. locate_template() /data/www/ap/cms/wp-includes/general-template.php:171, referer: http://192.168.50.4/ahr/
PHP 7. load_template() /data/www/ap/cms/wp-includes/template.php:521, referer: http://192.168.50.4/ahr/
PHP 8. require() /data/www/ap/cms/wp-includes/template.php:564, referer: http://192.168.50.4/ahr/
PHP 9. uw_breadcrumbs() /data/www/ap/cms/wp-content/themes/uw-boundless/breadcrumbs.php:1, referer: http://192.168.50.4/ahr/
PHP 10. get_uw_breadcrumbs() /data/www/ap/cms/wp-content/themes/uw-boundless/inc/template-functions.php:296, referer: http://192.168.50.4/ahr/

On the old peopledir page:
http://www.washington.edu/home/peopledir/

Drop down menus on the right-hand side of the screen aren't aligning with their menus. (see screenshot)

I have installed the Boundless theme in /themes/uw-boundless and noticed some file not found messages in the console. See attached

$url = get_site_url() . "/wp-content/themes/uw-2014/assets/headers/suzzallo.jpg";

checking the WordPress API it looks like get_template_directory_uri() is the correct way to avoid using hard coded paths for images

https://developer.wordpress.org/reference/functions/get_template_directory_uri/
$url = get_template_directory_uri() . "/assets/headers/suzzallo.jpg";

The Quick Start guide doesn't say to use uw-2014 folder for the theme! You might consider updating the quick start to say the theme MUST be placed in the uw-2014 folder under wp-content/themes if the hard coded paths are not fixed

Not sure if this has been addressed, however, i have come across a problem with the header search feature being set to search all of UW when the site im working with is not concerned with all of UW. To keep patrons focused on the local content i would like to set it so when the search button is initiated there is a focus on the current site and even dropt the all of UW option all together. In short: I would like to have an option to set current site as default or as the focussed item.

When Clicking the Search Icon you get the radio buttons with: All the UW or Current site and all of UW is default. I have found it easier to just build my own search drop down and drop this backbone driven search feature. AKA: just like the UW homepage.

Any tips, additional information on customizations im not aware of or code adjustments would be greatly appreciated.

This theme depends upon jQuery, provided by the domain ajax.googleapis.com, in class.uw-scripts.php.

This domain is not available behind the Chinese Great Firewall, compromising site functionality for Chinese visitors. We recently received a ticket from a visitor who was unable to use our site because of this issue. We probably learned of this issue only recently because of recent actions by the Chinese government to restrict VPN access. See for example Apple removing VPN clients from its Chinese app store.

I propose to include a copy of jQuery in the uw-2014 theme, and include that file (as opposed to the blocked Google-hosted file) in class.uw-scripts.php. Of course the file included in the theme should be identical to the one currently retrieved from Google.

I'll submit a pull request to this effect!

Quick Links partially exposed on leadership page(s)
http://www.washington.edu/leadership/

Also on 404 pages:
http://www.washington.edu/blarg

OSX: Safari, Firefox, Chrome

On most websites that use the Boundless theme, secondary pages have an h1 heading marking the main heading of the page, which is correct. This should be the first heading on the page. Currently the site title (element with class="uw-site-title") is tagged as h2, which breaks the outline of the page. This should be changed to a div element.

For example, consider the Regents page:
http://www.washington.edu/regents/

The site title is "Board of Regents" and is incorrectly tagged as h2. The main heading is "UW Board of Regents" and is correctly tagged as H1. Removing the orphaned h2 results in a clean, logical outline that starts with an h1, thereby reducing cognitive load on screen reader users.

The selected month and year text in the Formidable Plugin calendar widget are the same color as the background, see attached picture. The two top boxes that appear to be blank contain the month and year. When I activate the WordPress Twenty Fifteen theme, the month and year are visible.

The search form is triggering multiple errors in SiteImprove for all websites using the template. Here's a summary of the problems:

• The <select> field (for mobile) has no label. Solution: Add aria-label="Search scope" to <select>
• The submit button, radio buttons, and select field are all outside of the <form> element. They should be inside the <form> element.
• An outermost <div> containing all search widget content (div.uw-search-wrapper) should include role="search"

Solution: Add lang="en" to <html> element.

This is triggering a Level A accessibility error in SiteImprove for all sites using the theme.

It looks like when i'm trying to implement GCS the same as it's done on the main UW website, it's not working properly. There are two different parameters used in the search on the top ?s and ?q. Since ?s is a standard WP search parameter, it's working just fine, but ?q does not redirect properly to the new template. I've noticed that on your main UW website you are using a plugin http://www.washington.edu/wp-content/plugins/uw-template-hierarchy/ which I believe is solving the problem, but I can't get it anywhere.

Can you place some additional documentation on implementing GCS on this theme? This functionality has been hardcoded into theme with the UW links and it's not very easy to change it.

Thanks for the help on this one,
Best,
T.

In the file: content-page-noheader.php

There is a function called text_cut(), that is expecting 3 parameters. It looks like it is only called in that same file down below (), and is called without a value for $text. In the latest version of PHP, this causes a error.

<a role="main" id="main-content" href="#main_content" class="screen-reader-shortcut">Skip
to main content</a>

The skip link on site pages incorrectly uses the role of "main." The "main" landmark role is to be used for the main content section of a web page.

Description

This is in response to my comment on Issue #13.

Looking at other keyboard navigation and accessibility patterns on the web, we have determined that individual slides in a slideshow element should not have their own tab stops. Rather, when the slideshow element itself has focus, keyboard navigating users should be able to navigate the slides using arrow keys. Hitting TAB when the slideshow element already has focus, should take focus to the next element on the page.

Steps to Reproduce

1. Open any commonly-used browser (IE, Firefox, Chrome) and navigate to a page hosting the slideshow component (e.g. http://www.washington.edu/research/)
2. Use TAB to navigate to the point where the slideshow component has just received focus
3. Hit TAB or SHIFT-TAB one more time

Expected Result

• Case: TAB: the next element on the page (the one after the slide show) receives focus
• Case: SHIFT-TAB: the previous element on the page (the one prior to the slide show) receives focus

Actual Result

With both TAB and SHIFT-TAB, the slideshow will advance to the next slide

When attempting to delete a visibility option for a widget, the Save button never becomes clickable. This issue appeared in WordPress 4.9.9. Most likely a javascript issue.

To Reproduce

1. Navigate to Appearance > Widgets
2. Add a new widget, click the visibility button.
3. Add more than one visibility settings and hit save.
4. Reload the Widgets page.
5. Click on the widget you created and click Visibility.
6. Delete one of the visibility settings. The Save button will appear greyed-out, not allowing you to save.

Hi,

I use the Github Updater plugin extensively to manage updates for themes and plugins that do not reside on wordpress.com.

Would it be possible to make the UW Theme (and possibly the various UW plugins) compatible with the Github Updater plugin?

In essence this means that the theme's style.css header needs to be updated with an additional declaration. See Github Updater usage. A site administrator will then be able to update the theme through the site's dashboard interface, as long as proper theme versioning is maintained.

Thanks for your consideration and kind regards,

Jasper Bleijs
Department of Global Health, University of Washington

When adding a YouTube video (which presumably uses a YouTube plugin or widget), the embed code provided by YouTube has some accessibility errors. Until Google addresses this problem, could these be fixed dynamically after the widget is loaded? The errors:

• The <iframe> element includes frameborder="0", which is obsolete and fails HTML5 validation. It also has width and height attributes, which are valid but could also be replaced with CSS, thereby attaining full separation of content from presentation.
• The <iframe> element needs a title attribute. I recommend title="YouTube video player"

I'd wonder if you would consider using wp_nav_menu, as opposed to wp_list_pages to build your sidebar menu on the theme.

I think your sidebar menu is hampered by the fact it can't detect your full dropdown nav structure. A big use case I think it's missing is any custom post type (CPT) won't show up. Or you might have a non-hierarchical CPT that someone wants to stick into nav.

I think having one UW Sidebar menu (that mirrors DawgDrops) is good. It removes the need for child themes or forks to make new menus and add them as needed in their theme. It also enforces consistancy between the sidebar menu and DawgDrops universally across your theme users.

I'd be happy to help build this, but want to know if you had another thoughts on this choice before coding anything.

We're building a child theme based on the Boundless theme and pulled changes to uw-2014 within the past week.

After rebuilding our child theme CSS, I noticed the mobile menu is no longer hidden for desktop screens. I took a look at uw.mobile-menu.less and noticed lines 2 and 4 set "display: block" instead of "display: none". Is this correct? If so, then it must mean I'm missing a new component in my child theme, although I can't detect what.

Our child theme is not overriding any of the parent theme's mobile menu styles.

Thank you.

SiteImprove is tossing up an error for "non-distinguishable links" because the two "UW Today" links (one under "News & Events" and one in the Quick Links sidebar) have slightly different URLs. They're both functionally the same but the former uses "http://uw.edu/news/" and the latter uses "http://www.uw.edu/news". If you standardize on one of these URLs that will reduce the number of accessibility errors in SiteImprove reports for all sites.

Shawna Litterski in Payroll reported that descenders are cut off in text entered in the search box. See screenshot

Hi,

Issue: can't add persons using the contact list widget.

WP version: 4.7.2
uw-2014 version: latest master pull

Hoping you can confirm or recreate this issue.
Using the Contact list widget I run into a javascript ReferenceError which appears to be related to the uw.contact-widget.js script. The following error occurs when clicking the "Add person" button.

Chrome:
see attached log file
staff.washington.edu-1487885738456.txt

Firefox:
13:39:57.552 ReferenceError: number is not defined 1 load-scripts.php:4:1
anonymous https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:4:1
m.template/c https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:141:15201
Ha/< https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:3:20829
.each https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:2:2879
n.prototype.each https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:2:844
Ha https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:3:20787
.append https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:3:22791
https://staff.washington.edu/jbleys/wordpress/wp-content/themes/uw-2014/assets/admin/js/widgets/uw.contact-widget.js:10:5
n.event.dispatch https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:3:12392
n.event.add/r.handle https://staff.washington.edu/jbleys/wordpress/wp-admin/load-scripts.php:3:9156

Kind regards,
Jasper Bleijs
[email protected]

Description

Using keyboard (TAB) navigation on a page with a slideshow, the slideshow component shows no visual indication of receiving focus. This occurs only with IE and Chrome.

Steps to Reproduce

1. Open a browser -- either Internet Explorer (version tested = 11.0.9600) or Chrome (version tested = 45.0.2454.99 m)
2. Navigate to a page that hosts the slideshow component (e.g. http://www.washington.edu/research/)
3. Use TAB to navigate through the page to the point where the slideshow component has focus

Expected Result

The slideshow element visibly indicates focus to the user. In other words, the element itself or the navigation controls within the element are outlined or highlighted in some way.

Actual Result

The slideshow element shows no visible indication of having focus.

Additional Notes:

I logged this as follow-up to my comment on issue #13

Description

In Firefox, when navigating via TAB through UW-2014 themed page on small-device screen resolution, the mobile menu toggle button does not visibly display focus.

Repro Steps

1. In Firefox (e.g. version 40.0.3), navigate to a UW-2014 themed page (e.g. http://www.washington.edu/brand/brand-guide/brand-pillars/)
2. Reduce horizontal window size of the page until the "dawgdrops" menu is replaced by the H1 page header and the mobile "MENU" toggle button
3. Refresh the page (F5)
4. Use the TAB key to navigate through the elements on the page to the breadcrumbs.
5. As you TAB through the breadcrumbs, the "MENU" button should receive focus after the next-to-last breadcrumb. TAB to give the "MENU" button focus.

Expected Result

The "MENU" button displays an outline or other indication that it currently has focus. This works with Chrome (version 45.0.2454.85 m) and IE (version 11.0.9600).

Actual Result

In Firefox (version 40.0.3), the "MENU" button does not display any visual indication of having focus

Not a showstopper by any means, but something you might want to be aware of. I just installed uw-2014 and created a child theme from it. I get this warning whenever I create or edit a post or page:

Warning: call_user_func_array() expects parameter 1 to be a valid callback, class 'UW_Media_Credit' does not have a method 'add_media_credit_shortcode_to_tinymce' in /nfs/bronfs/uwfs/hw00/d43/uwmpaf/wp-includes/class-wp-hook.php on line 286

Grepping 'add_media_credit_shortcode_to_tinymce' brought me to wp-content/themes/uw-2014/setup/class.uw-media-credit.php, line 12:

add_filter( 'mce_external_plugins', array( $this, 'add_media_credit_shortcode_to_tinymce' ) );

WebAIM's WAVE (web accessibility checker) has identified several contrast issues on the UW home page. See the WAVE Report for details. WAVE adds icons to the page to flag problematic content. In the left sidebar, there's a tool for navigating through the issues. In the sidebar, click the "Contrast" button to see the various contrast issues. There are essentially two general problems:

1. Content where contrast is legitimately too low (e.g. black on brown "Quick Links"; brown on tan text in the News & Events boxes).
2. Content where text appears over a background image. In this case, the content block should have a defined background-color that has WCAG-compliant contrast with the foreground text. The background color is important because it serves as a fallback in case the background image fails to load.

The main "Dawgdrops" navigation menu was build with accessibility in mind, but accessibility methods related to navigation menus have evolved since then. The current menu needs the following changes, which I've grouped into two phases:

Phase 1
The following changes don't require any changes to HTML structure of the menu; therefore should be fairly easy to make I think.

• Remove role="application" from div.dawgdrops-inner
• Remove aria-haspopup="true" from each top-level menu item (<a>)
• Remove role="group" and aria-expanded from the <ul> that contains each submenu
• Currently, when a top-level menu item has keyboard focus, the corresponding submenu can be opened by pressing either Enter or down arrow. Remove support for down arrow for this purpose. If no submenu is open, users should be able to use the down arrow for its default browser function (which for most browsers is scrolling the page down within the viewport).
• If a user presses the Escape key when focus is anywhere within the <nav>, all open submenus should close, regardless of whether they were opened using the keyboard or mouse. (Currently, if a submenu was opened with a mouse, it's impossible to close it with the keyboard).
• If a user opens a submenu by hovering with the mouse, all previously open submenus should close, even those that were opened using the keyboard.
• If a user opens a submenu by pressing the Enter key on a top-level submenu, all previously open submenus should close, even those that were opened using the mouse.
• When a submenu opens, the aria-expanded attribute on the top-level menu item should change to "true". Conversely, when the submenu closes, the aria-expanded attribute should change to "false". This change should occur regardless of whether the submenu was opened/closed with keyboard or mouse (currently the attribute value only changes on keyboard events).

Phase 2
Currently, the top-level menu item is serving two roles. It serves the role of a link (<a>) that leads to a new page, but also as a button that triggers the submenu. This isn't allowed in HTML, and there are only two ways to solve it:

1. Change the top-level links to <button> elements, so they serve the button role, but no longer link to other pages, or
2. Add a <button>, adjacent to the link. There's already a visual indicator to the right of each link, so this could be accomplished with little or no change to the visual design. That visual indicator just needs to be a <button>.

I've been told in the past that option 1 is not an option: Those top-level links are not expendable. If that's still true, option 2 would be the one to implement. The following additional steps assume there is both a link and a button for each top-level menu item:

• Move the aria-expanded and aria-controls attributes from the link to the button.
• Add aria-labelledby to the button, with a value that matches the id of the link (e.g., aria-labelledby="academics").
• Currently if the top-level menu item (the link) has focus, pressing Enter triggers the submenu, whereas pressing Space follows the link. Remove the Enter key event listener, so Enter and Space both follow the link.
• Add keydown event listeners on the button, so pressing Enter or space when the button has focus both trigger the submenu.

Looking in our apache logs, I noticed a bunch of errors pointing to line 29 of /content-page-noheader.php.

The problem is that the text_cut() method defined further up in the file is expecting an argument for the 'text' parameter. The call to text_cut() in line 29 provides no value.

You could fix either of two ways: (1) remove 'text' from the list of parameters -- it looks like the function will overwrite whatever is passed anyway, or (2) provide a default value, such as 'null'.

I would have submitted a PR, but I apparently don't have permissions.

Thanks,
Matt

What versions of Wordpress has this theme been tested against?
We are currently on 4.2.4 and are planning on upgrading to 4.4

thanks
Jim

On mobile devices running Chrome, extremely long text on links inside <ul class="footer-links"> will begin to overlap with the '/' divider. Issue can be seen on admit.washington.edu, or any other UW-2014 site if the link text is long enough.

This affects links larger than ~40 characters, depending on the specific text.

Keyboard users can open search by pressing enter or space when the search icon has focus. When the search field appears their focus is placed in that field, and if they press escape their focus is returned to the original icon. This is all perfect. However, if instead of pressing Escape they press Tab (with or without entering a search term), their focus deviates from what's expected:

1. On pages with search-related radio buttons, they seem to land on the radio buttons. However, there's no visual indication that this has happened. Initially I was unclear where focus had gone, and discovered it was on the radio buttons by using the up/down arrows to change the selected radio button.
2. On pages with no radio buttons (e.g., the home page) pressing tab from the search field sends users to the top of the document, starting with the "Skip to Main Content" link.

Expected behavior would be to land on the submit button first. Then if there are radio buttons, land on those second (and in both cases, there should be clear visible indication of focus).

With or without radio buttons, users should land back on the search toggle after they've cycled through the search fields, since that's where they started. Then they can continue on where they left off, or select the toggle to close the search.

Hello.

One of our testers noticed this problem with the theme in IE 11. I'll just copy and paste the bug we have in our tracking system here as is. I did notice that repro step no. 4 has been fixed on the home page since the original bug was filed, so we'll need to pull those changes into our theme. Repro step no. 5 still seems to be a problem on the home page but oddly enough not on the research site.

Description

Keyboard Navigation in IE 11 causes Search icon and Quick Links label to display incorrectly.

Impact

User sees the incorrect icon and shifted text until they open a new page. Once a new page is opened the icon and Quick Link text revert to the correct format.

Repro Steps

1. While using IE 11, open http://www.washington.edu/research/
2. Click on the purple banner to set the focus
3. Tab to move the focus through the navigation until the "Search" icon is selected
4. Tab once more to move away from the search option. User will see distorted search icon. (This looks like it's been fixed.)
5. Tab two more times through Quick Links. User will see distorted Quick Links label

Expected Results

Search icon and Quick Links label should display normally throughout the user's experience and should not display as distorted.

Actual Results

Search icon and Quick Links label display distorted until user refreshes page or navigates to a new page.

On iOS with VoiceOver running, the user can tap "Open Quick Links" to make the Quick Links menu appear. However, once the menu is visible, it is impossible to close it again. The only focusable and recognizable elements are the Quick Links menu items.

This has been tested most recently with iOS 8.4 on both an iPhone and iPad Air 2, but had been previously reported using earlier versions of iOS.

Expected behavior: the "Open Quick Links" button would change to "Close Quick Links" when the menu is open, and that button should remain focusable at the top of the Quick Links menu. If the user advances focus from the last item in the menu, the tab order should cycle back to the top (to the "Close Quick Links" button).

Forgive me if there's a workaround for this. I'm not the most skilled PHP guy.

I'm extending your UW object in a child theme and implementing some features, dropping some, and including some of my own. While your use of the page templates meta box is really quite nice, we have a different need for it. Currently, I can only comment out line 17 of functions.php to get my functionality to work. I'd like to continue to get bug fixes etc from you guys. Could you move those require statements to inside your UW class file?

Hi, guys,
I'm from the UW Grant and Contract Accounting Department, and we're using your guys' new wordpress theme for our new Intranet. Our old intranet is very deprecated and early 2000s.

I've been able to modify your theme for our uses, however, I see that you guys keep doing bug fixes, and I just want to fix our codebase with a stable version or fork from a stable version. Everytime I merge my project back with your guys' to essentially receive "updates", there is a lot of code cleanup that needs to be done, and I can't determine whether merging is worth it.

can you take up tagging releases again?
I see that the only release is 0.8 which was pretty much when you guys initially released.

Here's another set of issues that were reported by the testers in ORIS. I'm copying and pasting the bug story we have in our tracking system. You can substitute the URL in repro step no. 1 with http://www.washington.edu/brand/html-web-components/ and the effect should be the same.

Description:

The slider/slideshow carousel on on Research home page has accessibility issues. The carousel arrows do not highlight when the tab focus is on them, it has a double tab stop for each slide and stories do not advance appropriately.

Impact:

Users that use tab or voice functionality are not able to access the carousel's controls and view the slide stories.

Repro Steps:

1. Open http://www.washington.edu/research/
2. Using tab, navigate to the slider/slideshow element
3. Press the tab key several times while watching the lower left corner of the browser window for the selected url
4. Press enter to view story
5. Press tab keys

Expected Result

1. The slider/slideshow should be highlighted when tab focus is on it
2. There should only be one tab stop for each slide story
3. The user should expect the first tab into the carousel to land on the first slide.
4. From the first slide, the user should be able to hit enter to view the current slide's story or tab forward to land on the arrow controls
5. The arrow controls should advance the slides if the user hits the enter key.
6. If the user tabs from the last arrow, they should tab out of the carousel and into the flow of the rest of the Research home page's content.

Actual Result:

1. Slider/slideshow is not highlight, the only way user can tell where they are is by reading url in lower left corner of browser screen.
2. Each slide story has two tab stops instead of one
3. When the user hits enter to view the story they are not able to tab to arrow controls
4. The user can only hit backspace to leave the slide story and that takes them back to the top of the Research home page instead of to the slide carousel where they were previously.

Regarding release tags, our team (in UW's Office of Research Information Services) is curious if there's a rationale driving when a v is used. For example, the most recent release is 1.4.9 but the release prior is v1.4.9. The two have the same version number, but contain different fixes. It could also be that 1.4.9 was intended to be v1.4.10 and a step was missed in the release process to increment as expected (as has happened to us on more than one occasion).

<nav id="desktop-relative" aria-describedby="mobile menu that is not
visible in the desktop version"></nav>

Aria for the above code is not correct. The aria-describedby attribute should not contain an actual description. It should instead reference the id of the element that describes this element.

If the contents of the thinstrip links aren't long enough, the quicklinks button wraps under the search button when the page width is between 768 and 991px. This is only an issue if a child theme modifies the standard thinstrip link content.

I propose adding min-width: 233px; to .uw-thinstrip div.align-right #search-quicklinks. Line 354 of uw.thinstrip.less.

We are having issues converting to the boundless theme from the older UW theme. We are seeing many errors in the apache error log as well as some pages failing to load, the header is displayed but there is no content.

To eliminate as many variables as possible we performed the following:

installed clean copy of wordpress

in the wp-config.php file changed
define('WP_DEBUG', FALSE);
to
define('WP_DEBUG', TRUE);

Refreshed page, checked apache error log. No errors

added Boundless theme, activated boundless theme, refreshed page.

the followinig errors were logged in the apache error log

PHP Notice: Undefined property: UW_QuickLinks::$items in /data/www/wp/wp-content/themes/uw-boundless/setup/class.uw-quicklinks.php on line 52, referer: http://192.168.50.4/
PHP Notice: Undefined variable: menu in /data/www/wp/wp-content/themes/uw-boundless/setup/class.uw-quicklinks.php on line 64, referer: http://192.168.50.4/

activated the Wordpress 2015 theme. No errors recorded in the apache error log file

Activated the Boundless theme
added 4 pages, one home page three child pages, navigated to a child page

the following errors were logged in the apache error log

Undefined offset: 0 in /data/www/wp/wp-content/themes/uw-boundless/page.php on line 10
PHP Notice: Undefined offset: 0 in /data/www/wp/wp-content/themes/uw-boundless/page.php on line 10, referer: http://192.168.50.4/index.php/home-page/child-page-1/
PHP Notice: Undefined offset: 0 in /data/www/wp/wp-content/themes/uw-boundless/setup/class.uw-sidebar-menu-walker.php on line 68, referer: http://192.168.50.4/index.php/home-page/child-page-1/
PHP Notice: Undefined offset: 0 in /data/www/wp/wp-content/themes/uw-boundless/page.php on line 44, referer: http://192.168.50.4/index.php/home-page/

activated the Wordpress 2015 theme. No errors recorded in the apache error log file

tested WordPress 4.2.4 and Wordpress 4.4

I'm showing only the root cause of the error, each error is 8 to 15 lines

We are using the theme on our website (http://depts.washington.edu/uwmxl/) whose URL has been masked (http://www.wxml.math.washington.edu/). The theme looks a bit weird on the masked URL on desktop (I checked on Google Chrome and Microsoft Edge). Both websites look fine on mobile phones.

Under Settings -> General, it has the correct URLs:
WordPress Address (URL) http://depts.washington.edu/uwmxl//wordpress
Site Address (URL) http://www.wxml.math.washington.edu
This does not solve the problem. :/

The nav element in the banner (with "Students", "Parents", "Faculty & Staff", etc.) has aria-label="role navigation", which is confusing since both "role" and "navigation" are ARIA terms. The value of aria-label should be a better reflection of the content and purpose of that menu. Maybe "Audience-based links"?

These two classes conflict causing a flicker on hover. In the following table, the first cell will flicker when the row is hovered over.

<table class="table table-hover">
    <tbody>
        <tr>
            <td class="active">Auit Manro</td>
            <td>1</td>
            <td>Vestibulum id ligula porta felis euismod semper.</td>
        </tr>
    </tbody>
</table>

If I have more than 8 items in a navigation dropdown, <div class="menu-bock"></div> is wrapped around the list items which conflicts with the styling of dropdown.

My guess is wrapChildren for uw.dropdowns.js.

In the child theme I'm working on I had tried editing the file directly (changing chunkSize) but it doesn't seem to have done anything.

Screenshot of dropdown with more than 8 items:

Screenshot of dropdown with less than 9 items (with added support for second level menus):

The uw-2014 theme has lang="en" on the <html> tag, as of a pull request in January 2017. However, that fix isn't reflected on the UW home page.