edx / ux-pattern-library Goto Github PK

The left sidebar doesn't scroll. This will become problematic once we add more patterns. I'll take a look at this.

FYI @talbs

The links lead to 404, and pertain to the website to view the working demo. This link may now be irrelevant as the working product has been released, in which case the links might be better removed.

See https://github.com/edx/edx-platform/pull/7877#discussion_r30045945 for more details.

What do you think of changing the href values of the sample links to a valid value? Currently, they reference "#". What if they referenced http://ux.edx.org or http://edx.org or self-referenced the parent container /elements/headings/ or #headings ?

See:

This is would cause an accessibility issue.

FYI @cptvitamin @clrux

When creating an extend to use in form field pseudo elements (i.e., &::-webkit-slider-runnable-track) the extend doesn't work when used more than once. We need to explore this further and investigate why Sass extends aren't working.

We're using mixins as a temporary solution.

We have error, warning, and success color palettes, but we should consider adding one for "info" too (usually a nice mix of blues).

cc @talbs

In a meeting with @cptvitamin on 18 Jun we uncovered the following issues with accessibility for this Pattern Library site. We plan to address them.

• skip text in header, is in a heading; doesn't need to be
• use only a single skip link to the main content
• put the individual patterns in regions (which eliminates the second skip link)
• when scrolling, and focusing on the area, set focus right before the title
• convert individual patterns to regions; show up in the regions dialog box
• add SR text to Permalink so we know what they're for; don't make sense out of context
• on tab activation, focus should move to container.
• make tabs buttons
• aria-describedby not working on some fields, even though the markup is correct
• placeholder text, if it includes patterns or formatting, needs to be permanently on-screen (helper text is great)
• add a label to the size slider for icons
• range slider is aria-valuemax, aluemin, valuenow (misisng the value parts now)
• contrast issues with disabled buttons and inputs, lighter p text
• hover states blue on gray (gets lighter, so check the contrast)

cc @talbs

Add language to the Accessibility Styleguide that emphasizes the importance of Heading and List semantics. Give examples of when it is important to include machine-readable semantics, even if visual indicators don't seem important, and vice versa.

Currently, any changes to the post, markup, or JS files require you to stop and restart the server manually. Can we have it watch and refresh automatically for these just as it does for CSS?

I noticed that we have examples for creating a hyperlink that appears to be a button. I'm OK with doing this but it would be a great opportunity to warn developers to do this with care. Links and Buttons are two different elements with different purposes and even different default controls (Enter/Return is used to activate a link and Space and Enter/Return is used to activate a button). For screen reader users, they appear in different out of context lists. For example, if a user is getting phone support, the support person would likely tell them to "Click on the login button" (a login button that was actually a link that looked like a button). They wouldn't find it in their list of buttons.

As a general rule of thumb: "Links go somewhere. Buttons do something."

As noted in #208, currently, select fields have an explicit height assigned to them. This seems fragile (with respect to cross browser rendering) and is currently cutting off some content within and around these elements.

TODO: Revise styling to not rely on height being specificed + revisit error/inline message UI.

Trying to install the pattern library as a bower dependency currently does not work. None of the dev dependencies are installed, and running bower install in the edx-ux-pattern-library directory does not work either. As an engineer, I would like to be able to use the UX pattern library without having to manually copy the SASS source.

As a developer from another team who uses the pattern library, I think it is crucial that proper Bower support be integrated with the pattern library (my original thought was NPM, but edX as an organization uses Bower to manage front-end dependencies). I tried playing around in my own branch, but ultimately this change is significant enough to warrant a dedicated effort. Some suggestions I have that could help this effort:

• Separate the Jekyll site from the actual library, using Bower to install the pattern library as a dependency. This will help demonstrate the modularity of the Pattern Library and clean up the respective codebases significantly.
• Include base .scss files with the pattern library that imports all of the components, so other developers don't have to do this manually. Right now, if you wish to use the pattern library, you must @import all of the components manually or modify a main-*.scss file, which currently resides in the documentation section of the repo. This makes it confusing for developers who wish to plug-and-play the library with little configuration. There should be a pattern-library-ltr.scss file as well as a pattern-library-rtl.scss file, which includes all of the needed imports.
• Place all build scripts under 'exclude' in bower.json and instead include a 'dist' or 'bin' directory with the compiled Javascript and CSS. Due to the lack of nested dependencies in Bower, developers will need to import precompiled Javascript in order to use it (the same goes for CSS developers who aren't using SASS). Build scripts won't be able to run because all of the dependencies will be siblings, not children (see here).
• Add all required SASS dependencies to a README. Because SASS can't be compiled without converting everything to CSS, SASS developers will need to import all of the dependencies manually in addition to the pattern library, similar to how imports are included in main-ltr.scss and main-rtl.scss. These dependencies should be formally documented in a README. JS dependencies wouldn't need to be documented given there is a compiled production version of the Javascript.

This is more of something to keep in mind, nothing extremely pressing. Just thoughts from someone who has tried using the pattern library. Let me know if you have any questions or comments. Thanks!

@talbs @frrrances

See https://github.com/edx/edx-platform/pull/7877#issuecomment-100960459 for more edX-related details as well as https://css-tricks.com/snippets/css/using-font-face/ for industry standards.

In short, we should only support ttf, woff, and woff2 formats